LDAP auth notes
Anyway, here at least is what I have done to get Ogo and Ldap working together:
Figure out what else you plan to use LDAP for
There really is no point using LDAP unless you plan (either now or later) to use it to integrate Ogo authentication with other services. Integrating Ogo logins with Email/Shell accounts, or Ogo logins with other web-based apps, or even with the new Samba 3 would probably give you the most value, so you might want to figure out what you need to get that stuff going while you are at it.
There are plenty of LDAP resources on the net : eg http://yolinux.com/TUTORIALS/LinuxTutorialLDAP.html#LDAPAUTH If you use Debian this wiki is worth its weight in gold : http://wiki.debian.net/index.cgi?LDAPAuthentication
Setup OpenLDAP
There are various howtos/docs for how to do this. Google is your friend.
Get a graphical LDAP Client
Download the LDAP Editor/Browser : its a graphical LDAP browser/editor (its Java based, so make sure your Java works first) and although I love the command-line as much as the next Linux geek, sometimes you really need to see what you are doing : at least this means that while learning to use LDAP you won't need to also learn how to operate your LDAP client (if you really know what you are doing of course, the command-line tools shipped with OpenLDAP will work fine too)
Add users to LDAP
Add some people. Ogo seems to use something like the fairly standard InetOrgPerson schema (or somesuch thing : I don't think Ogo obsesses over schemas: so long as there is a userPassword, Ogo seems to handle it). But since the whole point of LDAP is integration, what schema you use depends on what else your integrating with.
FYI: this works for me (try editing it and importing it as LDIF (then changing the password) using eg the LDAP browser/editor above) and it integrates with Unix accounts, which lots of other stuff also integrates with :
dn: uid=user,ou=People,o=YourOrganisation,dc=yourdomain,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: user
givenName: Some Random
sn: User
loginShell: /bin/bash
uidNumber: 1001
gidNumber: 100
mail: user@yourdomain.com
homeDirectory: /home/randomuser
userPassword: aa0y959N2nSV6
cn: Some Random User
NB: Ogo seems able to populate some of the account properties from LDAP: eg it seems to find the email above : I wonder what other properties it can get from LDAP??
NNB: its a good idea to either to create an LDAP record for "root" (and then NOT use that as the system's root user): or even better to change the uid of "root" before switching over to LDAP to that of one of your ordinary users. Otherwise you won't be able to log in as the administrator.
Set the appropriate Ogo defaults
Put the Following in NSGlobalDomain :
LSAuthLDAPServer = ldap1.yourdomain.com;
LSAuthLDAPServerRoot="ou=People,o=YourOrganisation,dc=yourdomain,dc=com";
Restart ogo, and log in using your LDAP users and passwords!
I think it is a better idea to change the default admin user to something other than root using this SQL: UPDATE person SET login =
ogoadmin, name =ogoadminWHERE company_id=10000 AND login=rootAND is_account=1;Some people might need this if the directory is also used for other logins. (ssh, email etc)
The according LDAP entry should look something like this:
dn: uid=ogoadmin, ou=Users, dc=domain, dc=tld userPassword:: e1pIQX0zeTc2Qmc0tlg1ZGlqS0 uid: ogoadmin objectClass: account objectClass: top objectClass: simpleSecurityObject
The used objectClass does not (or SHOULD actually not) affect Ogo's behavior when identifying a user. As the authentication happens using an LDAP bind, the used objectClass does not matter at all as long as the bind is successful. Unfortunately, Ogo has an extremely strange behavior when authenticating. Currently, it first searches for the user using an anonymous bind; it then checks whether there is a userPassword attribute or not; if not, auth fails at once. If yes, it will try to bind as the found user and if bind is successful, Ogo continues the login. This behavior is not very feasible when there are some ACLs active on the LDAP server that deny "read" (but allow auth) access to the userPassword attribute.
Replies to this comment