Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 78

c 

 
      

Ing. Roberto Chiabra


rchiabra@pucp.edu.pe / rchiabra@pe.ibm.com
che Agenda

‡ What is a directory?
‡ What is LDAP?
‡ che Anatomy of LDAP
‡ Identifying the LDAP server and its attributes
‡ Deciphering the LDAP schema
‡ Mapping the LDAP attributes to a client
application
þbjective

‡ che objective of this class is to provide


you with the following:

± Basic understanding of LDAP


± Understanding of proper usage of LDAP
± How LDAP relates to our applications
che Agenda

‡ „  

‡ What is LDAP?
‡ che Anatomy of LDAP
‡ Identifying the LDAP server and its attributes
‡ Deciphering the LDAP schema
‡ Mapping the LDAP attributes to a client
application
What is a directory?

‡   ²public or private resource lists containing


names, locations, and other identifying information²are
essential tools often taken for granted in our daily
activities. cypically these directories provide information
about people, places, or organizations as part of an
overall solution. For example, a telephone is virtually
useless without a directory to correspond names with
telephone numbers. Historically, most directories were
only available in printed form.
What¶s a Directory Service

‡ A way to find things in a distributed environment

‡ Directories have two main parts:

± Database
‡ Schema - describes the data
‡ Distributed

± Protocols
‡ Access the data
‡ Manipulate the data
Directory Services Versus Databases

‡ Both have much in common


± chey allow access to stored data

‡ A Directory Service <> Database


± Directories are designed to be read-mostly
± Does not do well with very
frequent updates
± cypically Distributed in Nature
Directory Client/Server Interaction
Directory Foundation: X.500
‡ In 1988, the International þrganization for Standardization (ISþ and the
International celecommunications Union (IcU introduced the X.500
standard. X.500 defines the protocols and the information model for an
application and network platform agnostic directory service. As a distributed
directory based on hierarchically named information objects, X.500
specifications characterized a directory that users and applications could
browse or search.

‡ che X.500 paradigm includes one or more Directory System Agents


(DSAs ²directory servers²with each holding a portion of the Directory
Information Base (DIB . che DIB contains named information objects
assembled in a tree structure²defined by a Directory Information cree
(DIc ²with each entry having an associated set of attributes. Every
attribute has a pre-defined type and one or more associated values. þbject
classes, containing mandatory and optional attributes, are defined within a
directory schema. End users communicate with an X.500 DSA using the
Directory Access Protocol (DAP while the Directory System Protocol (DSP
controls interaction between two or more DSAs.
X.500: che Need for a Lightweight Alternative

‡ cransport
± LDAP runs directly over IP: Either cCP or UDP
‡ Functionality
± Simplifies X.500 functionality by eliminating low use features
‡ Data Representation
± LDAP uses simple string formats
‡ Encoding
± LDAP uses a simplified encoding rules

‡ 90% of the functionality, 10% of the cost!


che Agenda

‡ What is a directory?
‡ „  
‡ che Anatomy of LDAP
‡ Identifying the LDAP server and its attributes
‡ Deciphering the LDAP schema
‡ Mapping the LDAP attributes to a client
application
What is LDAP?

‡ LDAP stands for Lightweight Directory Assistance


Protocol
‡ Comes from the need of a smaller, less complex version
of X.500, another Directory Access protocol (DAP for
directory assistance
‡ LDAP is much simpler to implement and developer for,
and runs on top of cCP/IP unlike X.500
‡ che defacto standard for client name lookups to a server
used by millions of corporations and billions of users*..

*Statistic is made up. Did you know 56% of statistics are made up?
Who made LDAP?

‡ þpen Standard defined by Internet Engineering cask


Force (IEcF
‡ þriginal implementation of LDAP as server was University
of Michigan(1993
‡ Architecture designed to LDAP v3 specification
‡ Replication and Access Control are not yet standardized
in LDAP v3 specification
± LDUP - Lightweight Directory Update Protocol draft
± Access Control - working standard (no acronym
What Is LDAP?

‡ A Directory Service Protocol


± LDAPv2 ± RFC 1777 3 March 1995
± LDAPv3 ± RFC 2251 3 December 1997

‡ LDAP excels in 4 areas:


± Features
± Standards ± IEcF standard
± Implementation
± APIs
Major characteristics of LDAP directories

‡ Relatively Static Data - che data is rarely modified. How


often do you change your telephone number?
‡ Extremely Fast Read þperations - che directory is tuned
for high read performance because the data in the
directory is frequently read but rarely written or updated.
‡ Distributed - che data is located on a number of systems
on the network for redundancy, performance, and
scalability.
‡ Hierarchical -chis ensures there is an authoritative
source of the data in the directory system.
‡ þbject-þriented -- che directory represents elements
and objects. þbjects are created from object classes,
which represent a collection of attributes.
Major characteristics of LDAP directories

‡ Standard Schema - Directories use a standard schema


available to all applications making use of the directory.
Although Hal German notes, "chere are Sþ many
standards to choose from. chere is no guarantee which
schema you get out of the box!"
‡ Multi-Valued Attributes - Directory attributes can have
single or multi-values.
‡ Multi-master Replication - Unlike a traditional database,
directories are distributed over a large number of servers
on the network. che power of that concept is that
directories are self-healing. chat means if one system is
unavailable on the network, the client systems can get
the replicated information from another system in the
network.
cþ LDAP or not LDAP...

‡ Is the data relatively static?


‡ Does the data need to be distributed?
‡ Can the data be used by more than one application?
‡ Is the data multi-valued?
‡ Can the data or application take advantage of a
hierarchical relationship?
‡ Do you need flexible security options?
‡ Do you need single sign-on?
‡ Do you need distributed or delegated administration
capabilities?
che Agenda

‡ What is a directory?
‡ What is LDAP?
‡ c 
 
 
‡ Identifying the LDAP server and its attributes
‡ Deciphering the LDAP schema
‡ Mapping the LDAP attributes to a client
application
What do we use LDAP for?

‡ Corporations need an ³address book´ of all names and


group within the company.
‡ All of these names and groups can be stored on a
dedicated server called a ³Directory Server´
‡ LDAP is the standard protocol for access name & group
lookup on a directory server
‡ A centralized LDAP Directory Server means all
applications have access to one consistent name &
address book.
Anatomy of LDAP



 

R 
 

  
 
  
  


  


÷   

 

 
LDAP Architecture
Lightweight Directory Access Protocol (LDAP

‡ LDAP defines the following four components:

± !    . Defines the syntax of the data in


the directory.

±      . Defines how the data is


organized in the directory.

±  !"  . Defines how the information in the directory is


accessed in a secure manner.

± #!  . Defines the operations for querying and


modifying the directory.
che Data Model

‡ che data model is centered around entries which are composed of


attributes. Each attribute has a type and one or more distinct values.
chis defines what kind of information is allowed in the values. LDAP
data elements are string types. LDAP relegates the knowledge of a
value's syntax to the application program rather than lower-level
protocol routines.

‡ Which attributes are required and allowed in an entry are controlled


by a special  attribute in every entry. che values of this
attribute identify the type of entry (for example, commonName,
organization, and so on . che type of entry determines which
attributes are required, and which are optional. For example, the
object class commonName requires the surname and FirstName
attributes, but description and others are optional.
Entries, Attributes and Values
Entries, Attributes and Values
Entry (þbject Anatomy
c"&

 !
"
! !

"  ! $%

  

' 
&  ! $%

&   ! $%


che þrganization Model

‡  
 are organized in a Directory Information cree
(DIc and divided among servers in a geographical and
organizational distribution. Each entry, with the exception
of the root, has a parent entry. Each entry has a fully
qualified name: the Distinguished Name (DN . Each
component of the DN is called a Relative Distinguished
Name (RDN . che Distinguished Name for any entry is
constructed by concatenating the Relative Distinguished
Names of the entry's ancestors.
che þrganization Model
che þrganization Model
che Functional Model

‡ che functional model in LDAP defines the


operations for querying and modifying the
directory. It defines the operations for:
± adding an entry from the directory.
± deleting an entry from the directory.
± modifying an existing entry.
± changing the name of an existing entry.
± querying for an entry in some portion of the directory
based on a criterion specified by a query filter.
che Functional Model - Authentication

‡ þpen
± þpens a connection to a DSA
‡ Bind
± Authenticates a client to the DSA
± Method of authentication ± LDAPv3
‡ Unbind
± cerminates a client/server session
Functional Model Interrogation
Search components

  ( 
Š )* + *"&"+ * 

 *"&"+ * 
&

)*   +    + ! 

 '  
,
$ (  *-%+ ) + &! 

 !   ! 
.
+ + !
+ + ! &
Functional Model Interrogation
Search ± Basic Search Filter cypes

‡ Equality
± <attr>=<value>
± (sn=Dan
‡ Approximate
± <attr>~=<value>
± (sn~=Dann
‡ Substring
± <attr>=[<leading>] * [<any>] * [<trailing>]
± (sn=Da*
Functional Model Interrogation
Search ± Basic Search Filter cypes

‡ Greater than or equal


± <attr>>=<value>
± (sn>=Dan
‡ Less than or equal
± <attr><=<value>
± (sn<=Dan
‡ Presence
± <attr>=*
± (objectClass=*
Functional Model Interrogation
Search ± Complex Search Filter cypes

‡ And
± (& (<filter1> (<filter2>
± (& (objectClass=user (sn=Dan
‡ þr
± (| (<filter1> (<filter2>
± (| (sn=Dan (sn=c*
‡ Not
± (!(<filter1>
± (!(sn=Dan
Search Parameters
che Security Model
‡ Authentication
± Assurance that the opposite party (machine or person really is who
he/she/it claims to be.
‡ Integrity
± Assurance that the information that arrives is really the same as what
was sent.
‡ Confidentiality
± Protection of information disclosure by means of data encryption to
those who are not intended to receive it.
‡ Authorization
± Assurance that a party is really allowed to do what he/she/it is
requesting to do. chis is usually checked after user authentication. In
LDAP Version 3, this is currently not part of the protocol specification
and is therefore implementation- (or vendor- specific. chis is basically
achieved by assigning access controls, like read, write, or delete, to
user IDs or common names. chere is an Internet Draft that proposes
access control for LDAP.
che Security Model

‡ LDAP version 2 defines an authentication model based


on clear text passwords or Kerberos V4.1. LDAP version
3 defines an extensible model based on the Simple
Authentication and Security Layer (SASL . SASL uses a
layered architecture for using different security providers.
LDAP version 3 defines the packet formats of the SASL
requests and responses between the LDAP client and
server. It supports both security authentication and
encryption using different SASL mechanisms.

‡ In addition to SASL, LDAP version 3 also supports


secure connections using the Secure Sockets Layer
(SSL protocol.
Anatomy of LDAP

‡ LDAP consists of attributes, objects and values


arranged in a hierarchy.
‡ Getting access to these objects is generally
done by binding to the server and using search
filters to find specific information.
‡ che LDAP structure can be created or modified
by hand, or imported via a file called an µLDIF
file¶.
Anatomy of LDAP

‡ þbjects are generally the people or groups


stored in the LDAP directory.
‡ chese are arranged in a hierarchal tree
‡ Example: cn=PE -> o=ACME -> ou=Lima ->
cn=Users -> uid=rchiabra would tell us that user
rchiabra is in the Lima group which is part of the
ACME organization in Perú.
Anatomy of LDAP

m 

 
 

 
 

 




 
   


 




   
 




 
     
  
 

 

Anatomy of LDAP

‡ An attribute is a specific item defined in an entry,


and a value is what it is..

‡ Example:givenname=Roberto, sn=Chiabra,
mail=rchiabra@pupc.edu.pe,
phonenumber=511-555-1212
Anatomy of LDAP
Anatomy of LDAP

‡ An LDIF is a file that has these


objects and attributes already defined
in a text format that can be imported
into a directory server

‡ Importing a LDIF is the easiest (and


recommended way to set up your
own LDAP server
Anatomy of LDAP
LDAP Data Interchange Format (LDIF

dn: o=ibm.com dn: cn=John Smith, ou=people,


objectclass: top o=ibm.com
objectclass: organization objectclass: top
o: ibm.com objectclass:
organizationalPerson
dn: ou=People, o=ibm.com cn: John Smith
objectclass: organizationalUnit sn: Smith
ou: people givenname: John
uid: jsmith
dn: ou=marketing, o=ibm.com
ou: marketing
objectclass: organisationalunit
ou: marketing ou: people
telephonenumber: 838-6004
LDAP RFCs
‡ Developed by the Internet Engineering cask Force (IEcF in 1997,
the current LDAPv3 implementation is a renovation of LDAPv2,
which primarily tackles deployment limitations identified within the
previous version. LDAPv3 also enriches compatibility with X.500
along with enhanced integration with non-X.500 directories. LDAPv3
encompasses LDAPv2 within a new set of RFCs.
‡ LDAPv3 is a Proposed Standard currently defined by RFC 3377,
which includes, the RFCs below in addition to support for the
LDAPv2 RFCs listed above :
± RFC 2251 ± Lightweight Directory Access Protocol (v3
± RFC 2252 ± LDAP (v3 : Attribute Syntax Definitions
± RFC 2253 ± LDAP (v3 : UcF-8 String Representation of Distinguished Names
± RFC 2254 ± String Representation of LDAP Search Filters
± RFC 2255 ± che LDAP URL Format
± RFC 2256 ± A Summary of X.500(96 User Schema for use with LDAP (v3
± RFC 2829 ± Authentication Methods for LDAP
± RFC 2830 ± LDAP (v3 : Extensions for cransport Layer Security
Let's see...there is...

‡ LDAP - Lightweight Directory Access Protocol


‡ DNS - Domain Name Service
‡ DHCP - Dynamic Host Configuration Protocol
‡ Radius - Extranet/Internet/Wireless
authentication service
‡ Kerberos - Intranet infrastructure authentication
service
‡ PKI - Public Key Infrastructure
che Agenda

‡ What is a directory?
‡ What is LDAP?
‡ che Anatomy of LDAP
‡ !   
‡ Deciphering the LDAP schema
‡ Mapping the LDAP attributes to a client
application
calking to an Existing LDAP

‡ chere are only 3 things you need to consume


data from an existing LDAP server:
± Fully qualified DNS name or IP address (and port if its
not the default of 389
± Base DN for searching
± Credentials

‡ cypically customers want to deploy applications


and web server using their existing LDAP in their
infrastructure ± so lets see how to do that«
Get proper LDAP connection information
‡ Get the fully qualified DNS name and port:
che name and location of the server, and the port the LDAP
service is listening on
‡ Get the base DN: che first place in the LDAP hierarchy
tree to begin looking for names
‡ Get a sample user name to bind to if
necessary: Determine if anonymous binding is allowed,
and if the attributes needed are returned when bound
anonymously. If a user is needed, determine the format of the
name and password to connect to the LDAP server
Note: Active Directory typically will not list
any users or groups if bound to
anonymously
Get proper LDAP connection information
che Agenda

‡ What is a directory?
‡ What is LDAP?
‡ che Anatomy of LDAP
‡ Identifying the LDAP server and its attributes
‡      
‡ Mapping the LDAP attributes to a client
application
che Pieces of an LDAP DN«

‡ Here is a standard user full distinguished name:

uid=rchiabra,ou=users,dc=lima,o=ibm
che Pieces of an LDAP DN«

user prefix org unit

uid=rchiabra,cn=users,ou=lima,o=ibm

user suffix base DN


Acquire the proper tools«

‡ Softerra LDAP Browser or«


‡ Softerra LDAP Administrator or«
‡ Java based LDAP Browser (can import LDIF
files
± LDAP Browser/Editor
± JXplorer - A Java Ldap Browser

‡ Found on Google
Configuring JXplorer«

‡ Add the FQDN of the LDAP server


‡ Add the base DN desired (or fetch them
‡ Select the security level
‡ Add a binding name to verify the correct format of a user
‡ Save the values as a template

‡ Note: If you can bind with a long LDAP name, then your
application can find the user when configuration is
complete ± bind with users to verify they exist and are in
the correct format
Configuring JXplorer«
Gather information about the LDAP user«

‡ Determine if you want to log in with µcn¶ or µuid¶


or another attribute.
‡ Make sure an objectclass such as
µinetþrgPerson¶ exists.
‡ Determine the email attribute ± typically µmail¶.
‡ Most importantly ± select an user and click the
properties button to get the long LDAP name, for
example:
cn=Bob Garcia,ou=Lima,dc=tweb,dc=com
Gather information about the LDAP group«

‡ Determine what attribute designates the name of


the group ± typically µcn¶
‡ Determine the objectclass of the group ± typically
µgroupþfUniqueNames¶ or µgroupþfNames¶
‡ Determine the member attribute name ± typically
µuniquemember¶ or µmember¶
‡ Again importantly: select a group and click the
properties button to get the long LDAP name(full
DN :
cn=Bowling ceam,ou=Groups,dc=tweb,dc=com
che Agenda

‡ What is a directory?
‡ What is LDAP?
‡ che Anatomy of LDAP
‡ Identifying the LDAP server and its attributes
‡ Deciphering the LDAP schema
‡ ¢  
 
 

Applying þur LDAP Experience in the Real World

‡ In the ³real world´ companies take their many


applications and point to their LDAP server
‡ Having a centralized LDAP reduces
management of multiple directories such as new
passwords, name changes, department
updates, etc
‡ Many applications can hook into an existing
LDAP directory for authentication, user
information, authorization and mapping of
names to specific application needs, etc..
Applying þur LDAP Experience in the Real World

‡ co get some hands on experience, we are going


to configure comcat 5.0 to use an existing LDAP
server.
‡ chese same principles apply to other
applications

‡ Documentación
± http://jakarta.apache.org/tomcat/tomcat-5.0-
doc/realm-howto.html#JNDIRealm
Roles as explicit directory entries

‡ # Define an entry for the "tomcat" role


‡ dn: cn=tomcat,ou=groups,dc=mycompany,dc=com
‡ objectClass: groupþfUniqueNames
‡ cn: tomcat
‡ uniqueMember: uid=jjones,ou=people,dc=mycompany,dc=com
‡ uniqueMember: uid=fbloggs,ou=people,dc=mycompany,dc=com

‡ # Define an entry for the "role1" role


‡ dn: cn=role1,ou=groups,dc=mycompany,dc=com
‡ objectClass: groupþfUniqueNames
‡ cn: role1
‡ uniqueMember: uid=fbloggs,ou=people,dc=mycompany,dc=com
Configuring server.xml file«

] 


  




   
   

 ! 
 "#$%   % & &%  

'
 % & &%  




( 
)*+ "#$,


-
Roles as an attribute of the user entry

dn: uid=jjones,ou=people,dc=mycompany,dc=com
objectClass: inetþrgPerson
uid: jjones
sn: jones
cn: janet jones
mail: j.jones@mycompany.com
memberþf: role2
memberþf: role3
userPassword: janet
Configuring server.xml file«

<Realm
className="org.apache.catalina.realm.JNDIRealm"
debug="99"
connectionURL="ldap://localhost:389"
userBase="ou=people,dc=mycompany,dc=com"
userSearch="(mail={0} "
userRoleName="memberþf"
roleBase="ou=groups,dc=mycompany,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0} "
/>
LDAP with Java

‡ Java Naming and Directory Interface (JNDI


± http://java.sun.com/products/jndi/

‡ che Java Naming and Directory Interface (JNDI


is a standard extension to the Java platform,
providing applications based on Java technology
with a unified interface to multiple naming and
directory services. You can build powerful and
portable directory-enabled applications using
this industry standard
JNDI Architecture
Example of Java code using JNDI

// Global Variables
public static String INIcCcX =
"com.sun.jndi.ldap.LdapCtxFactory";
public static String MY_HþSc =
"ldap://w2kpro.pe.ibm.com:389";
public static String MGR_DN =
"cn=Manager,dc=tweb,dc=com";
public static String MGR_PW = "password";
public static String MY_SEARCHBASE =
"dc=tweb,dc=com";
public static String MY_FILcER = "cn=Luis Gerente";
Example of Java code using JNDI
// Hashtable for environmental information
Hashtable env = new Hashtable( ;

// Specify which class to use for our JNDI Provider


env.put(Context.INIcIAL_CþNcEXc_FACcþRY, INIcCcX ;

// Specify the host and port to use for directory service


env.put(Context.PRþVIDER_URL, MY_HþSc ;

// Security Information
env.put(Context.SECURIcY_AUcHENcICAcIþN,"simple" ;
env.put(Context.SECURIcY_PRINCIPAL, MGR_DN ;
env.put(Context.SECURIcY_CREDENcIALS, MGR_PW ;

// Get a reference toa directory context


DirContext ctx = new InitialDirContext(env ;
Using C# : Binding using an Identity

‡ // C# Library namespace
‡ using Novell.Directory.Ldap;

‡ // Creating an LdapConnection instance


‡ LdapConnection ldapConn= new LdapConnection( ;

‡ //Connect function will create a socket connection to the server


‡ ldapConn.Connect(ldapHost,ldapPort ;

‡ //Bind function will Bind the user object Credentials to the Server
‡ ldapConn.Bind(userDN,userPasswd ;
®Preguntas?
Example Directory cree with Attributes for a Small þrganization
Bibliografía

‡ Active Directory Service Interfaces -che Easy


Way to Access and Manage LDAP-Based
Directories (Windows Nc 4.0
± http://www.microsoft.com/technet/prodtechnol/winntas
/maintain/featusability/adsildap.mspx
‡ Active Directory LDAP Compliance
± http://www.microsoft.com/windowsserver2003/techinf
o/overview/ldapcomp.mspx
‡ Understanding LDAP
± http://www.microsoft.com/technet/community/events/n
etwork/tnq40004.mspx
Bibliografía

‡ ³Understanding LDAP - SG24-4986-00´


± http://www.redbooks.ibm.com/redbooks/SG244986.ht
ml
± http://www.redbooks.ibm.com/redbooks/pdfs/sg24498
6.pdf

‡ che Apache Jakarta comcat 5 Servlet/JSP


Container
± Realm Configuration HþW-cþ
± http://jakarta.apache.org/tomcat/tomcat-5.0-
doc/realm-howto.html

You might also like