LDAP Support

LDAP Support

User Modes

Conductor supports two modes of user authentication. “Database” mode uses locally defined users. In this mode users are administered through the conductor UI. LDAP mode authenticates users defined in an LDAP server. In LDAP mode an admin cannot administer users through the conductor UI.

Configuration

LDAP support may be enabled by editing two configuration files:

• Specify either “database” or “ldap” modes /usr/share/aeolus-conductor/config/settings.yml

• Enter LDAP server settings <pre>/etc/ldap_fluff.yml</pre>

• restart aeolus services <pre>aeolus-services restart</pre>

Support

User authentication information may be provided by the local Conductor database or an LDAP server but not both. However both local and LDAP user groups may be defined and used together. When LDAP users log in their LDAP groups are added to the session. User admins may create additional local user groups, assign permissions and add users to groups. Aeolus permissions may be assigned to LDAP groups via the conductor UI.

LDAP support is provided by ruby gem ldap_fluff. More information can be found here: https://github.com/jsomara/ldap_fluff

Developers and debugging

Setting up a local LDAP server

While Conductor can be configured to point to an external LDAP server , for development purposes it’s often easiest to set up a local LDAP server running on your development box. It’s easy~~- just follow these instructions (borrowed from Katello):

1. yum install openldap*

2. Create (anywhere, it’s just temporary) a content.ldif file with these contents (they are literal — don’t try to fill in “{crypt}” or anything):

   dn: dc=my-domain,dc=com dc: my-domain objectClass: top objectClass: domain

   dn: ou=People,dc=my-domain,dc=com ou: People objectClass: top objectClass: organizationalUnit

   dn: ou=Groups,dc=my-domain,dc=com ou: Group objectClass: top objectClass: organizationalUnit

   dn: uid=admin,ou=People,dc=my-domain,dc=com uid: admin cn: admin objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: admin uidNumber: 1001 gidNumber: 1001 shadowLastChange: 14846 shadowMax: 99999 shadowWarning: 7 homeDirectory: /home/admin gecos: Admin

   dn: uid=guest,ou=People,dc=my-domain,dc=com uid: guest cn: Guest objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: guest uidNumber: 1002 gidNumber: 1002 shadowLastChange: 14846 shadowMax: 99999 shadowWarning: 7 homeDirectory: /home/guest gecos: Guest

   dn: cn=admins,ou=Groups,dc=my-domain,dc=com objectClass: posixGroup objectClass: top cn: admins userPassword: {crypt}x gidNumber: 501 memberuid: admin

   dn: cn=users,ou=Groups,dc=my-domain,dc=com objectClass: posixGroup objectClass: top cn: users userPassword: {crypt}x gidNumber: 502 memberuid: guest 3. Make sure your LDAP server is stopped for a moment, with @service slapd stop@ (the OpenLDAP server is, quite intuitively, called "slapd") 4. Import the @content.ldif@ you just created, like so: @slapadd -l content.ldif@ 5. Fix ownership, with: @chown -R ldap.ldap /var/lib/ldap@ 6. Start 'er up: @service slapd start@ (don't forget to @chkconfig slapd on@ if you want it to start at boot)

   This provides two users: admin/admin and guest/guest.

   Debugging LDAP

   You can get a list of all users from an LDAP server (if it allows anonymous binds -- the default config used above does) with:

   ldapsearch -h localhost -p 389 -x -b 'ou=People,dc=my-domain,dc=com'
   
   

This will search localhost:389 for everyone in the “ou=People,dc=my-domain,dc=com” DN. -x enables simple authentication (versus SASL), needed even for an anonymous search. Note that this “my-domain.com” example should be customized for your setup; this one is pulled from our sample config above.

See also

• The Katello team has some additional documentation here
• The ldap_fluff gem that we use