Skip to content

OGo Docs

Sections
Personal tools
You are here: Home » Members » sim's Home » LDAP auth notes

LDAP auth notes

Document Actions
Some notes on setting up LDAP authentication in Ogo

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!

Created by chris
Last modified 2003-10-22 04:08 AM

Ogo Admin

Posted by hnt at 2004-02-19 02:53 PM

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 = ogoadmin WHERE company_id=10000 AND login=root AND 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.

Login Attribute can also be set

Posted by armand at 2004-02-22 01:56 AM

If the username to check for is not in the Ldap attribute uid,

Defaults write NSGlobalDomain LDAPLoginAttributeName

will set the login attribute to check for.

 

Powered by Plone

This site conforms to the following standards: