User Tools

Site Tools


ldap_integration

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
ldap_integration [2009/08/20 08:34] 172.26.0.166ldap_integration [2009/08/20 09:27] 172.26.0.166
Line 3: Line 3:
 ILRI uses an Active Directory server for user authentication, which is primarily used for Exchange e-mail services.  Active Directory is Microsoft's proprietary version of LDAP with a little extra special sauce.  Currently users have an Active Directory username and password for their Windows-centric single sign on and e-mail, and then they have a separate account for use with the HPC.  There exists functionality in Linux to look at Active Directory for user authentication. ILRI uses an Active Directory server for user authentication, which is primarily used for Exchange e-mail services.  Active Directory is Microsoft's proprietary version of LDAP with a little extra special sauce.  Currently users have an Active Directory username and password for their Windows-centric single sign on and e-mail, and then they have a separate account for use with the HPC.  There exists functionality in Linux to look at Active Directory for user authentication.
  
 +===== Notes =====
 +
 +==== Using ''ldapsearch'' on Linux ====
 +Try to search from a Linux machine which can talk to the AD server (HPC is behind firewall):
 <code>[aorth@shamba: ~]$ ldapsearch -x -H ldap://172.26.0.218:3268 -b "dc=ilri,dc=cgiard,dc=org" -D "cn=bioinfohpc,cn=users,dc=ilri,dc=cgiard,dc=org" -W "" <code>[aorth@shamba: ~]$ ldapsearch -x -H ldap://172.26.0.218:3268 -b "dc=ilri,dc=cgiard,dc=org" -D "cn=bioinfohpc,cn=users,dc=ilri,dc=cgiard,dc=org" -W ""
 Enter LDAP Password:  Enter LDAP Password: 
 ldap_bind: Invalid credentials (49) ldap_bind: Invalid credentials (49)
         additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece</code>         additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece</code>
-According to the web this error means the user does not exist.  Either I've specified the user's distinguished name incorrectly, or the account is not configured with the proper permissions to bind+According to the web this error means the user does not exist.  Either I've specified the user's distinguished name incorrectly, or the account is not configured with the proper permissions to bind: 
- +<file>HEX: 0×525 – user not found
-<code>HEX: 0×525 – user not found+
 DEC: 1317 – ERROR_NO_SUCH_USER (The specified account does not exist.) DEC: 1317 – ERROR_NO_SUCH_USER (The specified account does not exist.)
-NOTE: Returns when username is invalid.</code+NOTE: Returns when username is invalid.</file
- +==== binddn ==== 
-==== pam_cgiar_ldap.====+A note of possible interest regarding binding on Linux (from the [[http://lists.samba.org/archive/samba/2007-April/131385.html|samba mailing list]]): 
 +<file>AD domain controllers listen on the standard LDAPS port (636) and will  
 +only accept binds on that port.  You cannot bind as a user on port 389.  I  
 +don't think they support TLS on port 389, but I have no tried in a long  
 +time.</file> 
 +==== Domain controller vsGlobal catalog ==== 
 +<file>All Windows 2000/2003 AD domain controllers (including Global Catalog Servers) listen for LDAP requests on the standard LDAP port 389. However, domain controllers (including Global Catalog Servers) respond to LDAP queries on port 389 with AD information from within its own AD domain only. Again, this works fine in a single domain configuration but not in a multi-domain setup. Global Catalog Servers additionally listen for LDAP requests on port 3268, Microsoft's AD LDAP port. Global Catalog Servers respond to LDAP queries on port 3268 with AD information from the entire AD forest. In multi-domain AD environments, it is best to use port 3268.</file>
  
 +===== pam_cgiar_ldap.c =====
 +Someone hacked up a PAM module several years ago which could be dropped into a Linux server and allow AD authentication with minimal configuration.  See the documentation here: {{:cgiar-hpc-cop.doc}}
 <note warning>This no longer works! It relied on anonymous access to the AD server, but ILRI's Active Directory servers are configured to [[http://support.microsoft.com/kb/326690|disallow anonymous binds]].  These notes have been left here for reference only!</note> <note warning>This no longer works! It relied on anonymous access to the AD server, but ILRI's Active Directory servers are configured to [[http://support.microsoft.com/kb/326690|disallow anonymous binds]].  These notes have been left here for reference only!</note>
  
 This was working once, using a //slightly// customized PAM module, but broken when IT services disabled anonymous binding.  In order to use the module several steps are needed.  Download the module source and edit the code to point to the correct server, then compile it as shown below: This was working once, using a //slightly// customized PAM module, but broken when IT services disabled anonymous binding.  In order to use the module several steps are needed.  Download the module source and edit the code to point to the correct server, then compile it as shown below:
   * Compile the code:  ''gcc -fPIC  -c pam_cgiar_ldap.c''   * Compile the code:  ''gcc -fPIC  -c pam_cgiar_ldap.c''
-  * Link the code:  ''ld -x --shared -o pam_cgiar_ldap.so –lldap pam_cgiar_ldap.o''+  * Link the code:  ''ld -x --shared –lldap -o pam_cgiar_ldap.so pam_cgiar_ldap.o''
  
 **pam_cgiar_ldap.c**: **pam_cgiar_ldap.c**:
ldap_integration.txt · Last modified: 2012/02/06 08:43 by aorth