[lsc-changes] [Ldap Synchronization...] page changed: documentation:2.0:howtos:activedirectory

[webmaster]

A page in your DokuWiki was added or changed. Here are the details:

Date : 2014/03/04 16:57
Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0
IP-Address : 88.173.78.196
Hostname : mne69-10-88-173-78-196.fbx.proxad.net
Old Revision: http://lsc-project.org/wiki/documentation/2.0/howtos/activedirectory?rev=1367507744
New Revision: http://lsc-project.org/wiki/documentation/2.0/howtos/activedirectory
Edit Summary: removed
User : coudot

@@ -1,140 +1 @@
- ====== Synchronizing to/from Active Directory ======

- Microsoft's Active Directory is a standards-based LDAP directory (well, mostly). Therefore, it is quite easy to set up identity synchronization with a AD Domain Controller. Below are some tips to get around some of the specifics.
-
- You can see a complete configuration for syncing users between OpenLDAP and AD [[http://lists.lsc-project.org/pipermail/lsc-users/2010-May/000187.html|here]].
-
- ===== Anonymous access controls =====
-
- By default, anonymous access to Active Directory servers has almost no rights to read data. Create a technical account, and use that to give LSC access to the server.
-
- ===== Search results size limit =====
-
- As most LDAP servers, Active Directory limits the maximum number of results to a search. By default, this limit is 1000. Since LSC starts by doing a search for all identities in the directory, this means a maximum of 1000 entries will be synchronized.
-
- To work around this, LSC can use the [[http://www.ietf.org/rfc/rfc2696|Paged Results control]]. Set the following property for the source or the destination in //lsc.xml//, and LSC will read results by page, with no maximum limit.
- <code xml>
- <connection>
- <.../>
- <pageSize>1000</pageSize>
- </connection>
- </code>
-
- ===== Multi valued attributes size limit =====
-
- Active Directory limits the maximum number of values returned by a ldap search for multi-valued attribute. As an example, AD use Group objects which contains the multi-valued attribute member.
-
- By default this limit in AD 2008 R2 is fixed to 1500 values.
-
- If we have groups with more than 1500 members LSC could faild to correctly synchronize these groups.
-
- This limit is configurable in Active Directory (Windows 2008/2008 R2) using this [[ http://support.microsoft.com/kb/2009267|KB]]
- ===== Filter to find user objects =====
-
- Active Directory defines a **user** objectClass, which is used to represent user accounts.
-
- So, using a LDAP filter in a search to find users is easy, just write "(objectClass=user)". Well, **almost**.
-
- Actually, the **user** objectClass is also used to represent **computers** and **trust accounts**[1]. So you need to add some components to your filter to avoid selecting these as well. Two options:
- - Select the account type specifically: //(&(objectClass=user)(sAMAccountType=805306368))//
- - Exclude the sub-objectClasses explicitly, like this: //(&(objectClass=user)(!(objectClass=computer)))//
-
- See [1]: [[http://msdn.microsoft.com/en-us/library/ms679637(v=VS.85).aspx|SAM-Account-Type Attribute description]].
-
- Thanks to Alexey Wasilyev for this tip.
-
- ===== Indexing search attributes =====
-
- LSC performs lots of a searches on the same attributes (those specified in //lsc>tasks>taskname>service>pivotAttrs// node in //lsc.xml//). If this/these attributes are not indexed in Active Directory, this can make LSC seem to run very slowly.
-
- It is easy to index an extra attribute in Active Directory. On the Schema Master domain controller:
- - Open a new MMC controller: from the Start menu, choose "Execute..." and type in "mmc", then hit enter.
- - From the File menu, select "Add a component" and scroll down to "Active Directory schema", add, and click OK.
- - Select "Attributes" in the list that appears, then find the attribute(s) you want to index.
- - Right click on each one, and open their Properties.
- - Select the "Index this attribute in Active Directory" checkbox, and press OK.
-
- ===== Reading from a Global Catalogue in a multi-domain forest =====
-
- If your Active Directory forest contains multiple domains, then the LDAP server on each domain controller will only offer a view of the users in that domain.
-
- If you want to synchronize all accounts in the forest, you may access the Global Catalogue interface offered by selected Domain Controllers. This is a typical LDAP interface, on TCP port 3268, but is read-only. It is most useful to use this for your source, therefore.
-
- To make an Active Directory Domain Controller a Global Catalogue:
- - Open the //Active Directory Sites and Services// administration tool
- - Find the Domain Controller you want in the Sites/Servers list, and right-click on it to open it's //Properties//
- - In the window that appears, select the checkbox "Global Catalogue" and press OK
-
- ===== Specific attributes =====
-
- Active Directory contains some very useful specific attributes.
-
- A useful list of how these attributes map to settings in the AD user interface is available at http://portal.sivarajan.com/2010/07/aduc-and-ldap-reference-sheet.html.
-
- LSC offers some functions to read and/or update some of these.
-
- So far, we can:
- * read userAccountControl (for example to check account status, etc...)
- * update userAccountControl (for example, to enable/disable an account, force the user to change password on next login, set the password to never expire, etc...)
- * read lastLogonTimestamp to find out the number of weeks since last successful login throughout the Active Directory domain
- * set unicodePwd to create or replace the password
-
- Detail on how to do this is [[..:configuration:syncoptions:activedirectory|here]] for now.
-
- ===== Password Synchronization =====
-
- ==== Overview ====
-
- Synchronizing passwords with Active Directory is a common requirement, but generally a tricky subject. LSC does not solve this problem for you, but can help you achieve your goal. In particular:
-
- * **LSC can write a password to Active Directory**, given the original password in clear text (there is no way to update a password in AD if you only have a hashed password, in MD5 or SHA, for example).
-
- * **LSC cannot read passwords from Active Directory**.
-
- ==== Approaches ====
-
- There are several approaches to synchronizing passwords with Active Directory. A few we (the authors of LSC) have tried are metioned here. If you have other approaches, we'd love to hear about them.
-
- - Store passwords in your source repository, either in clear text or in a two-way encryption scheme (LSC includes tools to encrypt and decrypt such an algorithm: see [[..:configuration:syncoptions:security|here]]), then use LSC's [[http://lsc-project.org/javadoc/latest/org/lsc/utils/directory/AD.html#getUnicodePwd(java.lang.String)|AD tool-class]] to update the password in AD. [[..:configuration:syncoptions:activedirectory|here]] an example how to do this.
- - Use AD as your main password store, and configure an OpenLDAP directory server to redirect authentications there, via SASL and LDAP binds. See [[http://ltb-project.org/wiki/documentation/general/sasl_delegation|detailed documentation to set up OpenLDAP and saslauthd to bind to AD]].
- - Configure Active Directory to capture password changes, by either:
- - Notifying another server on user password changes, using the [[http://technet.microsoft.com/en-us/library/cc727636(WS.10).aspx|Password Synchronization]] component of Microsoft's **Services For Unix** addon.
- - Capturing the passwords, using [[http://passwdhk.sourceforge.net/|PasswdHk]], a password filter DLL.
-
- ==== Pitfalls ====
-
- Active Directory is, er, a little peculiar in it's handling of password changes. Here are some hints, to avoid being bitten by it's weird behaviour, like we have been :-)
-
- **Old password remains valid for an hour**
-
- As described in this [[http://support.microsoft.com/?id=906305|Microsoft Support article]], as of Windows Server 2003 SP1, once you've changed a user's password, the old password remains valid for an hour after the change. In effect, this means you can use both a users' old password and the users' new password to log in for one hour!
-
- **New password accepted in LDAP modify operation but not really accepted**
-
- In some cases (particularly with passwords containing special characters, such as non ASCII characters), Active Directory will accept a password update operation and return a "Success (0)" result for the LDAP modify operation, BUT the new password will not be useable.
-
- For this reason, we recommend to always check that a succesful BIND operation can be performed on the Active Directory with the new password after changing it. You can use the [[..:configuration:syncoptions:ldap|canBind* functions]] to do this.
-
-
- ===== Non-standard objectClasses =====
-
- Active Directory does not respect the **inetOrgPerson** objectClass definition, as specified in [[http://tools.ietf.org/html/rfc2798|RFC 2798]]. An explanation is provided below.
-
- LSC version 2.X can synchronize to and from Active Directory despite of this.
-
- The objectClass inheritance path defined in [[http://tools.ietf.org/html/rfc2798|RFC 2798]] is as follows:
-
- * top
- * person
- * organizationalPerson
- * inetOrgPerson
-
- However, in Active Directory, an extra objectClass, named **user** is inserted in this path:
-
- * top
- * person
- * organizationalPerson
- * user
- * inetOrgPerson
-
- This is documented by Microsoft in the [[http://msdn.microsoft.com/en-us/library/ms682282(VS.85).aspx|Active Directory Schema documentation]].