Tag: ldap

Bulk LDAP Operations

LDIF – Directory Import and Export using LDIFDE.EXE and LDAPMODIFY

 

You can obtain ldifde.exe from any existing domain controller – copy \\dcname\c$\winnt\system32\ldifde.exe  to your SYSTEM32 folder. The ldapmodify command is part of the openldap-clients package on Linux. Windows builds of the openldap clients are available. The data being imported is essentially the same, just the command line to invoke the program differs.

Using LDIF files to update LDAP data is facilitated if you know the directory schema attributes, especially those associated to the user object class.  Active Directory schema is well documented on MSDN – base Active Directory schema can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/active_directory_schema_site.asp and the extensions made by Exchange are documented at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/wss_ldf_AD_Schema_intro.asp

LDIFDE is a command line program which runs with currently logged on user’s credentials – this means that your ID can write changes to AD using LDIFDE.  Please do not play with this program in the production Active Directory domain but rather test writing to a test domain.

 

LDIF Export

Exporting directory information is fairly straight forward:

 

ldifde –f filename.txt –d “ou=base,DC=windstream,DC=com” –p subtree –r “(&(attribute=value)(otherattribute=othervalue))” –s domaincontroller.windstream.com –l “attribute1, attribute2, attribute3 …”

 

-f File to contain exported data
-d Search base
-p Search scope
-r RFC-2254 compliant filter
-s Domain controller from which to obtain data
-l Attributes to be returned (eliding this command will return values for all attributes)

 

This will create a file named ljlexport.txt of all e####### users with email addresses whose accounts are located under WINDSTREAM.COM\WINDSTREAM\IT.  The file will contain, for each user, their logon ID (sAMAccountName), email address (mail), account status (userAccountControl), display name, and telephone number.

ldifde –f ljlexport.txt –d “ou=IT,ou=windstream,DC=windstream,DC=com” –r “(&(sAMAccountName=e*)(mail=*))” –s neohtwnnt836.windstream.com –l “sAMAccountName, mail, userAccountControl, displayName, telephoneNumber”

 

-r specifies the search filter and can become a rather complex query depending on what you are looking for — & is an AND filter, | is an OR filter.  ! can be used to find unmatched values and * works as a wildcard

“(&(mail=*)(!sAMAccountName=n99*))”        find all mail enabled accounts which are not N99’s for instance.

“(&(sAMAccountName=e0*)(!(employeeID=*)))”      Find all employee accounts with no employee ID specified

“(&(mail=*)(|(sAMAccountName=n99*)(sAMAccountName=g99*)))”            mail enabled accounts which are either n99’s or g99’s

“(&(objectClass=user)(objectCategory=person))”        Real user accounts, objectClass=user alone will return a lot of things you don’t believe are users J

“(&(objectClass=user)(objectCategory=person)(telephoneNumber=813*))”     Real user accounts with phone numbers in the 813 area code

“(&(objectClass=user)(objectCategory=person)(msExchHomeServerName=*SCARLITNT841))”       Real user with mailboxes on SCARLITNT841

 

-d specifies the search base (subtree search by default) – you can use “DC=windstream,DC=com” to get the entire directory or something like “ou=Central,ou=windstream,DC=windstream,DC=com” to just get users within the Central OU.

 

LDIF Import

Importing Directory Information is not so straight forward and again do not play with this program in the production Active Directory domain.  You need to create an ldif import file to make changes to objects.  A sample file content:

dn: cn=Landers\, Lisa,ou=GPOTest,ou=IT,ou=windstream,dc=windstreamtest,dc=com
changetype: modify
add: proxyAddresses
proxyAddresses: smtp:lisa@newtestdomain.windstream.com
-
replace: telephoneNumber
telephoneNumber: 501-905-4305
-
delete: mobile
mobile: 501-607-3750
-
delete: facsimileTelephoneNumber
-
 
dn: cn=Ahrend\, Sam,ou=IT,ou=windstream,dc=windstreamtest,dc=com
changetype: modify
replace: mDBUseDefaults
mDBUseDefaults: FALSE
-
replace: mDBStorageQuota
mDBStorageQuota: 190000
-
replace: mDBOverQuotaLimit
mDBOverQuotaLimit: 200000
-

Provided you have an import file, the syntax of the command is ldifde –i –v –k –y –f filename.txt  

 

-i LDIFDE import operation
-v Produce verbose output
-k Ignore constraint violations (and entry exists errors on add)
-y Lazy commit
-f File name to be imported

 

 

Changetype Add

A changetype of add is used when the entire object does not currently exist – this ldap operation creates a new object with the attributes specified in the stanza.

 

dn: cn=TestingGroup 10001,ou=testing,ou=it,DC=windstream,DC=com
changetype: add
cn: TestingGroup 10001
distinguishedName: cn= TestingGroup 10001,ou=testing,ou=it,DC=windstream,DC=com
name: TestingGroup10001
sAMAccountName: TestingGroup10001
objectClass: group
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=windstream,DC=com
groupType: -2147483646
managedBy: cn=Landers\, Lisa,OU=GPOTest,ou=IT,OU=WINDSTREAM,DC=windstream,DC=com
member: cn=Landers\, Lisa,OU=GPOTest,ou=IT,OU=WINDSTREAM,DC=windstream,DC=com
member: cn=Ahrend\, Sam, ou=IT,OU=WINDSTREAM,DC=windstream,DC=com
legacyExchangeDN: /o=WINDSTREAMEXCH/ou=First Administrative Group/cn=Recipients/cn=TestingGroup10001
mailNickname: TestingGroup10001
reportToOriginator: TRUE

 

This example will create an e-mail enabled global security group named “TestingGroup 10001” under windstream.com – it – testing.  Both Sam and I will be listed as members of  the group and I will be listed as the group owner.  Add operations can be chained together with just a blank line between them should you need to add multiple objects in batch.

 

Any mandatory attributes for the schema classes need to be included (handled by ldifde works too) or the add operation will fail.  Attributes not valid for the object classes will cause the operation to fail as well.  If an object already exists, no change will be made even if some of the attributes specified differ from the values within AD.

 

Changetype Delete

Delete is used to delete the entire object – so be extra careful here.  The syntax is quite simple – the DN of the object to be removed and a line that says “changetype: delete”.  Again, multiple operations can be chained together with just a blank line.

 

dn: cn=TestingGroup 10002,ou=testing,ou=it,DC=windstream,DC=com
changetype: delete
 
dn: cn=TestingGroup 10003,ou=testing,ou=it,DC=windstream,DC=com
changetype: delete
 
dn: cn=TestingGroup 10004,ou=testing,ou=it,DC=windstream,DC=com
changetype: delete
 
dn: cn=TestingGroup 10005,ou=testing,ou=it,DC=windstream,DC=com
changetype: delete
 

Changetype Modify

Modify is used to change attributes on an existing object.  Modify can be used to add, replace, or delete an attribute.  The example above has two different stanza’s (separated by a blank line).  Within each stanza several operations are made:

 

First to add another email address to the secondary email addresses.  For a multi-value attribute (member, proxyAddresses …) changetype: modify\nadd: attribute adds another value to the attribute.  For single-valued attributes modify/add will fail if a value is present.

dn: cn=Landers\, Lisa,ou=GPOTest,ou=IT,ou=windstream,DC=windstream,DC=com
changetype: modify
add: proxyAddresses
proxyAddresses: smtp:lisa@newtestdomain.windstream.com
-

The next operation replaces the telephone number with the value specified – this will overwrite the existing value.  Be careful not to replace multi-value attributes

replace: telephoneNumber
telephoneNumber: 501-905-4305
-

The next operation deletes the mobile phone number with the value specified – if the value does not match, a change is not made.  This can be used as a failsafe, in this case only delete my mobile telephone number if the value is what I expect it to be, or to remove entries from multi-value attributes.  Delete the member of the group which is the specific member listed without changing the other group members, for instance.

delete: mobile
mobile: 501-607-3750
-

The next operation deletes the fax number – regardless of content the value is removed.

delete: facsimileTelephoneNumber
-

A blank line separates the two stanzas and a new object is specified.  Again the modify/replace option is used which will change the attributes to the values specified.

dn: cn=Ahrend\, Sam,ou=IT,ou=windstream,DC=windstream,DC=com
changetype: modify
replace: mDBUseDefaults
mDBUseDefaults: FALSE
-
replace: mDBStorageQuota
mDBStorageQuota: 190000
-
replace: mDBOverQuotaLimit
mDBOverQuotaLimit: 200000
-
 
dn: cn=Landers\, Lisa,ou=IT,ou=windstream,DC=windstream,DC=com
changetype: modify
replace: mDBUseDefaults
mDBUseDefaults: TRUE
-

Changetype ModDN
ModDN changes the object’s distinguishedName.  This is interesting as it can be used to move users – this example would move my account into the Central OU under ACI

dn: CN=Landers\, Lisa,OU=GPOTest,OU=IT,OU=WINDSTREAM,,DC=windstream,DC=com
changetype: moddn
newrdn: CN= Landers \, Lisa,OU=Central,OU=WINDSTREAM,DC=windstream,DC=com
deleteoldrdn: 1

 

ModDN can also be used to rename the object’s display in administrative listings:

dn: CN=Landers\, Lisa,OU=GPOTest,OU=IT,OU=WINDSTREAM,,DC=windstream,DC=com
changetype: moddn
newrdn: CN= Landers\, Jane, OU=GPOTest,OU=IT,OU=WINDSTREAM,,DC=windstream,DC=com
deleteoldrdn: 1

You would of course want to modify/replace at least givenName and displayName on the object dn to avoid confusion – otherwise my middle name would appear in active directory users and computers but my first name in Outlook.  I would modify the attributes first – if you modify the DN first, you need to remember to use the new DN for subsequent attribute value changes.

dn: CN=Landers\, Lisa,OU=GPOTest,OU=IT,OU=WINDSTREAM,,DC=windstream,DC=com
changetype: modify
replace: givenName
givenName: Jane
-
replace: displayName
displayName: Landers, Jane
-
 
dn: CN=Landers\, Lisa,OU=GPOTest,OU=IT,OU=WINDSTREAM,,DC=windstream,DC=com
changetype: moddn
newrdn: CN= Landers\, Jane, OU=GPOTest,OU=IT,OU=WINDSTREAM,,DC=windstream,DC=com
deleteoldrdn: 1
-
 

LDAP Directories

Origins

The International Telecommunication Union, ITU http://www.itu.int/home/index.html, is an organisation of the United Nations (sorry, Carra, now I guess all directories are on par with poodles) which submits recommendations for the coordination of global telecom and radio systems.  The Telecommunication Standardisation Sector, ITU-T, is the branch submits recommendations for telecommunication standards.  ITU-T was formerly known as Comité Consultatif International Téléphonique et Télégraphique, CCITT.

Published in volume eight of the 1988 CCITT Blue Book, X.500 is the recommendation for “The Directory”.  Additional recommendations X. 501, 509, 512, 518, 519, 520, 521, 525, and 530 farther defined ITU’s idea for directory service functionality.  Once ITU-T put forth the recommendation, several international standards bodies got involved, and eventually yielding the 9594-1 standard from ISO (from isos, name used by the International Organisation for Standardisation) and IEC (International Electro-technical Commission).   I’ve got the 1993 version (./9594-1-X.500.A4.ps) but never bothered to get the updates.

X.500 Components

Some of the terminology used within the X.500 recommendation is used in non-X.500 directories.  If you want to more about these or what they do, read the ISO/IEC standard

  • Directory Information Base (DIB) is used to store the directory data
  • Directory Information Tree (DIT) is a hierarchy within the DIB
  • Directory Service Agent (DSA) is a server which stores the DIB
  • Directory User Agent (DUA) is an application interface over which queries are made to the DSA
  • Directory Access Protocol (DAP) is the method used by the DUA to communicate with the DSA
  • Directory System Protocol (DSP) is used for communication between DSA’s
  • Directory Management Domain (DMD) contains DSA’s within an organisation
  • Directory Management Organization (DMO) is the actual organisation of the DMD
  • Directory Information Shadowing Protocol (DISP) is used to replicate information between DSA’s in a DMD
  • Directory Operational Binding Management Protocol (DOP) is policies which define the administrative information exchanged between DSA’s

LDAP

X.500 directory access protocol in its actual form involves a lot of overhead we just don’t want to incur to keep a guy, his password, his address, and his phone number all available somewhere.  Lightweight Directory Access Protocol, LDAP, retains the directory structure of X.500 with a simplified TCP/IP based access protocol.  Referrals were simplified and the replication protocol generalized.

The LDAP Technical Specification Roadmap is maintained by the Internet Engineering Task Force, IETF, as RFC 4510 (http://tools.ietf.org/html/rfc4510).  The multiple RFC’s encompassed by LDAP are included in section 1, “The LDAP Technical Specification”.

Directory Components – Schema:

Every directory has a schema set which defines its components.  The schema defines what type of objects exist in the directory and what attributes are valid for those objects.  Schema “attributes” are types of values which can be on an object – anything from an asset ID number to a vendor ID.  Schema “classes” are categories of entries which can be made – and a group of attributes that category means the object can have.  An attribute can be “mandatory” within a class – for example a user account may need a cn value, an objectClass, and an objectCategory.  You cannot make a user account without these values.  The remaining values in a class are “optional” – you may or may not have facsimileTelephoneNumber on your account.

There are three types of classes: abstract, auxiliary, and structural.  Abstract classes are classes which an object cannot directly be – cannot be the object’s objectClass – but are used through subordinate classes to define valid and required attributes..  Auxiliary classes are somewhat like abstract classes in that an object cannot be an auxclass – auxclass’s are instead ‘attached’ to structural classes to create additional valid attributes for the class.  Structural classes are the objectClass “things” you can make within the directory – a user account, a print queue, or even a replication partnership.  The semantics may vary between directory services, but the idea remains.

If you wish to add additional attributes to your objects, you need to extend the directory schema.  I will note here that Novell seems to allow undefined schema extensions.  Normally an organisation is issued an OID number (Object Identifier).  A private enterprise would normally request an OID assignment from IANA (existing assignments are published to http://www.iana.org/assignments/enterprise-numbers) or ANSI.  ANSI’s cost money whereas IANA’s don’t.  Guess which we use!  1.3.6.1.4.1.12704 has been issued to Alltel, 1.3.6.1.4.1.25709 has been issued to Windstream.  Additional decimal number groups past the organisation’s enterprise number can be sub-allocated within the organisation.  .5 within Alltel is used within the AD schema extensions, and 5.1 is specific to the test domain where 5.0 is specific to the production domain.  The breakout an OID number within Alltel’s production AD is:

1                              iso
1.3                            org
1.3.6                          dod
1.3.6.1                        internet
1.3.6.1.4                      private
1.3.6.1.4.1                    enterprise
1.3.6.1.4.1.12794              Alltel
1.3.6.1.4.1.12794.5            Alltel Active Directory
1.3.6.1.4.1.12794.5.0          Production AD
1.3.6.1.4.1.12794.5.0.1.#      Production AD Classes
1.3.6.1.4.1.12794.5.0.2.#      Production AD Attributes

So 1.3.6.1.4.1.12704.5.1.2.7 (cSOBESPolicy) is an attribute within the allteltest.com test domain – the seventh one at that and 1.3.6.1.4.1.12704.5.0.1.1 (alltelPerson) is a class in the production alltel.com domain (the first and only one).  A different numbering scheme off the “1.3.6.1.4.1.12794” base should be used for other directories.

Once you have created new attributes and appended an aux-class to an existing class, you may (iPlanet, IBM LDAP) need to restart the LDAP service or you may (Active Directory) need to wait for the change to propagate.  Our customized attributes are associated to an aux-class of user called alltelPerson. 

Please do not randomly modify the schema – especially in Active Directory.  In AD you cannot remove the entries.  You can deactivate an attribute but it cannot be deleted.

Directory Components – Structure:

A directory structure will begin at its root – an “O”, organisation name, in iPlanet/NDS/IBM LDAP, or “DC”, domain component, in Active Directory.  OU’s, Organisational Units may be contained under the directory root to provide some organisation to the objects housed within the directory.  You may also see CN’s under the domain root –common name with an objectClass of container.  There may be several layers of OU’s or containers before you find the “leaf” objects – users, contacts, printers, servers, whatever.  The fully qualified LDAP syntax of an object begins at the object and ‘walks’ up the tree – “cn=e0082643,ou=core1,ou=lit,ou=ar,ou=sc,o=alltel” for my ID in the ALLTEL-TREE for example.  “Special” characters are encoded or escaped as required – “cn=Landers\, Lisa,ou=GPOTest,ou=IT,ou=ACI,dc=alltel,dc=com”

LDAP Operations

Connections to LDAP are normally made on port 389 for clear text and 636 for encrypted.  Ldap.alltel.com (iplanet), metatreeldap.alltel.com (CSO metatree), litexchldap.alltel.com (active directory ldap), and any NetWare 6.0+ server within the alltel-tree use these standard ports, but alternate ports can be assigned within most directory servers.

Once a connection is made, it may be possible to query the directory.  A limited set of data should be returned as any directory enumeration at this point is done under an anonymous credential.  To specify the user with which you wish to perform directory operations, a BIND must be made.

Search operations include a base and scope (where to begin the search and how deep to traverse the directory under the base), and usually a filter (what to search for) and attributes requested.  Ldapsearch.exe (Win32 available from \\neohtwnlx810.windstream.com\NDSSupport\softlib\misc\ldaputils\) can be used to search an LDAP compliant directory.  Ldapsearch options: -h hostname.alltel.com  -b “ou=search,ou=base,dc=alltel,dc=com” –s “scope” –D “cn=user,ou=location,dc=alltel,dc=com” –W “RFC-2254 compliant filter” attributes to return go here

The search scope can be base (just the object defined as the search base), one (the search base and one level under), or sub (everything subordinate to the search base).  Eg:

ldapsearch -h litexchldap.alltel.com -b “ou=GPOTest,ou=IT,ou=ACI,dc=alltel,dc=com” -s “one” -LLL -D “cn=Landers\, Lisa,ou=GPOTest,ou=IT,ou=ACI,dc=alltel,dc=com” -W “(&(objectClass=user)(mail=*))” displayName mail

The –W option prompts for a password, alternately -w “PasswordGoesHere” can be used.  Once a password has been supplied in this example, the display name and email address for users who have an email address will be returned:

dn: CN=ACI WWC LDS Undeliverables,OU=GPOTest,OU=IT,OU=ACI,DC=alltel,DC=com
displayName: ACI WWC LDS Undeliverables
mail: ACI.WWC.LDS.Undeliverables@alltel.com
 
dn: CN=bob,OU=GPOTest,OU=IT,OU=ACI,DC=alltel,DC=com
displayName: bob
mail: bob@alltel.com
 
dn: CN=Landers\, Lisa,OU=GPOTest,OU=IT,OU=ACI,DC=alltel,DC=com
displayName: Landers, Lisa
mail: Lisa.Landers@alltel.com
 

Additional operations to add objects, delete objects, modify objects, and modify the distinguished name of the object can be done.  More information on this will be provided later.