mail us  |  mail this page

contact us
training  | 
tech stuff  | 

LDAP: DNs for Authentication

The DN describes the contents of attributes in the tree (the navigation path) that will reach the specific entry required OR the search start entry.

A DN is comprised of a series of RDNs (Relative Distinguished Names) found by walking UP the tree (DIT) to its root (or suffix or base) and is written LEFT to RIGHT unlike the file system analogy you see quoted everywhere which is written RIGHT to LEFT.

The DN is written LEFT to RIGHT.

When a new entry is added to the DIT a DN is used to tell the server how to structure (or place) the entry. An example of new entries being added is shown below as an LDIF file (they could equally have been added using an LDAP Browser or a specialised LDAP client tool).

version: 1

## version not strictly necessary but good practice to include for future

## DEFINE DIT ROOT/BASE/SUFFIX ####
## uses RFC 2377 format

## dcObject is an AUXILIARY objectclass and MUST
## have a STRUCTURAL objectclass (organization in this case)
# this is an ENTRY sequence and is preceded by a BLANK line

dn: dc=example,dc=com
dc: example
description: The best company in the whole world
objectClass: dcObject
objectClass: organization
o: Example, Inc.

## FIRST Level hierarchy - people 
# this is an ENTRY sequence and is preceded by a BLANK line

dn: ou=people, dc=example,dc=com
ou: people
description: All people in organisation
objectClass: organizationalUnit

## SECOND Level hierarchy - people entries 
# this is an ENTRY sequence and is preceded by a BLANK line

dn: cn=Joe Schmo,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Joe Schmo
sn: Schmo
uid: jschmo
mail: joe@example.com
mail: j.schmo@example.com
ou: sales

The above LDIF creates the directory structure shown:

In general, it does not matter what attribute value is used to add a new entry as long as the 'dn:' is unique. The above example has chosen to use cn=Joe Schmo in the last entry for this purpose. It could equally have been, say, uid=jschmo. LDAP searching can use any attribute or combination of attributes and can thus find entries irrespective of the 'dn:' value used to create the entry. To avoid excessive searching, in most cases it makes sense to use a 'dn:' value that represents an entry's most frequently used access DN. Thus in the above example is would be assumed that most directory access would use the cn= attribute.

However, if the entry is going to be used for user authentication, the creation 'dn:' value becomes extremely important and defines the only possible logon DN. The reason for this behavior is that authentication is accomplished using an LDAP Bind operation which demands a Bind DN (and an optional password) and does NOT allow any search operation. Thus, the Bind DN CAN ONLY be the DN used when the entry was added or created. the following LDIF file creates a dn using the uid attribute which is more normal for authentication LDAP systems:

version: 1

## version not strictly necessary but good practice to include for future

## DEFINE DIT ROOT/BASE/SUFFIX ####
## uses RFC 2377 format

## dcObject is an AUXILIARY objectclass and MUST
## have a STRUCTURAL objectclass (organization in this case)
# this is an ENTRY sequence and is preceded by a BLANK line

dn: dc=example,dc=com
dc: example
description: The best company in the whole world
objectClass: dcObject
objectClass: organization
o: Example, Inc.

## FIRST Level hierarchy - people 
# this is an ENTRY sequence and is preceded by a BLANK line

dn: ou=people, dc=example,dc=com
ou: people
description: All people in organisation
objectClass: organizationalUnit

## SECOND Level hierarchy - people entries 
# this is an ENTRY sequence and is preceded by a BLANK line

dn: uid=jschmo,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Joe Schmo
sn: Schmo
uid: jschmo
mail: joe@example.com
mail: j.schmo@example.com
ou: sales

The above LDIF creates the directory structure shown:

LDAP standards, somewhat confusingly, do not use any special terminology when refering to the DN used to intially create the entry. However, this 'creation' DN is sometimes - especially in the context of LDAP used within Microsoft's AD - referred to as a Principal DN, primarily due its use as a Principal (Security Principal) within Kerberos.



Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.

Contents

tech info
guides home
intro
contents
1 objectives
big picture
2 concepts
3 ldap objects
quickstart
4 install ldap
5 samples
6 configuration
7 replica & refer
reference
8 ldif
9 protocol
10 ldap api
operations
11 howtos
12 trouble
13 performance
14 ldap tools
security
15 security
appendices
notes & info
ldap resources
rfc's & x.500
glossary
ldap objects
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox

Search

web zytrax.com

Share

Icons made by Icomoon from www.flaticon.com is licensed by CC 3.0 BY
share page via facebook tweet this page

Page

email us Send to a friend feature print this page Display full width page Decrease font size Increase font size

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Software

LibreOffice
OpenOffice
Mozilla
GitHub
GNU-Free SW Foundation
get-dns

Organizations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

Site

CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2024 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
hosted by javapipe.com
web-master at zytrax
Page modified: January 20 2022.