Comments on LDAP Authentication In Linux

Nice work, thank you !

You may add a note that on Fedora, migrations tools are in /usr/share/openldap/migration/

Add references to others (of good quality too) like http://www.grennan.com/ldap-HOWTO.html

I had the same Problem in Debian Lenny and found an answer as a comment from another www-user - look at:

http://www.stanford.edu/services/directory/openldap/configuration/custom-schema.html

and include the mentioned 

http://www.stanford.edu/services/directory/openldap/configuration/krb5-kdc.schema

as schema into your slapd.conf - this file isn't installed with e.g. Debian Packages - so You have to do it manually.

Hope, this helps ;-)

This is certainly the solution. Maybe Debian can add this scheme to the migration tools package? 

OPTS="-h 'ldaps:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"

There is no sock file on CentOS5. I also had to put 'bind_policy soft' in /etc/ldapd.conf otherwise ldap wouldn't start and hang forever but now just keeps dumping into logs :

Jan 22 23:43:46 hybrid runuser: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid runuser: nss_ldap: could not search LDAP server - Server is unavailable Jan 22 23:43:46 hybrid runuser: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid runuser: nss_ldap: could not search LDAP server - Server is unavailable Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: could not search LDAP server - Server is unavailable Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: failed to bind to LDAP server ldap://domain.local/: Can't contact LDAP server Jan 22 23:43:46 hybrid slapd[16452]: nss_ldap: could not search LDAP server - Server is unavailable

Don't understand why I'm getting this after generating the LDIFs from migration tools:

ldapadd -D "cn=admin,dc=home-network" -W -f /tmp/passwd.ldif -x -c
Enter LDAP Password:
adding new entry "uid=root,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

adding new entry "uid=daemon,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

adding new entry "uid=bin,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

adding new entry "uid=sys,ou=People,dc=home-network"
ldap_add: Invalid syntax (21)
    additional info: objectClass: value #5 invalid per syntax

...Lot's more of the above

Any ideas why this is happening and how to fix it?

that error comes becouse you don't have a schema included in your slapd.conf for kerberos5 authentications.

You have to remove all lines with krb5 occurrences in /tmp/passwd.ldif

 I spent some time to understand it...

Use this,

  ldapadd -x -h <LDAP IP Address> -D cn=xxxx,dc=xxx,dc=xxx,dc=xxx -f  /xxx/xxx.ldif -W

It works to me.

i would use an account with minimal rights to recursive searching from the LDAP.

Your "Manager" should only created for this function an should not have an right to interactive logon.

Given that the PADL migration scripts don't specify a minimum UID or GID for migration, and that one may wish to use an LDAP store across multiple distros where UIDs and GIDs may not always be the same at install, and where new accounts may be created during the installation of software, how much of that data should we really have in our LDAP servers?

The gentoo ldap document even goes so far as to test the function of nss-ldap after migration by using getent to test for multiple root accounts.

 As far as I can imagine, the only groups and users we should have in LDAP are those which are associated with human and automated logins which we wish to administrate from a central location and wish to make available across systems and/or applications.

 However, where an account needs to be a part of a group created by the system, this brings up the obvious question. Either location we decide to locate this information creates a potential for inconsistency. The lesser of two evils appears to be to add LDAP users to file based groups on a system by system basis, which then creates another type of management overhead.

 If we are to keep all the migrated information in LDAP, then do we leave all or some of the duplicated entries in the system? Do we leave system sensitive accounts such as root in LDAP?

It isn't a good idea to remove the root account (among others) from the system files as tempting a thought as it is to have a centrally managed root password (there are better ways to deal with root access anyway), and how do we then manage the concept of multiple distributions with differing uid/gid setups? Much of the latter has been mitigated by a fairly standard stock set of uid/gid mappings, and through the creation of many accounts on an install basis. I am not sure at all that any given package will check first to see that an account/group has been previously created via some reliable method (getent) before performing a creation, which could create another overhead in administration.

What are your experiences with, and solutions to, managing authentication data across a collection of systems using LDAP?

Hi , i configured ldap client to search from ldap server, now i want to authenticate any user who want to login into my linux system using Ldap. please can somebody tell me the steps to do..

Hi guys,

I have CPanel  hosted server and I want to implement LDAP authentication on it. The OS is a CentOS8. It seems that the .htaccess file is not working for me. When I acces the site I was presented with the user and password window but I have a 501 error after I put the credentials and hit login button.

Eny ideea why I have this 501 error?