LDAP user authentication in OpenEdge - Michael Jacobs

Hello Bart,

I hear that you are having some trouble resolving a user's DN by using an LDAP search. It sounds like you are failing in the internal-procedure resolveUserDN. Is this correct?

The resovleUserDN procedure performs an LDAP search using a sub-tree search which should start at the LDAP search-root DN and traverse the entire sub-tree. My thought is that 1) we may not actually be searching the entire sub-tree; 2) we have the wrong search filter and are not getting the correct attribute matching.

Do you have the returned error from LDAP? Have you enabled the debug MESSAGE statement output (m_lDebug)?

I found that having another LDAP query tool available verify entry and attribute accessibility was very useful in providing feedback very quickly for developing the LDAP search-root DN and LDAP search attribute filters.

Post any more information back to this thread and we will try and fix the problem you are having.

Mike Jacobs

Hi Michael,

Thanks for helping me out with this problem.

I've added the code I use.

The active directory tree is as follows :

> coopman.be (dc)

> coopman (ou)

> users (ou)

> Finance (ou)

> sales (ou)

> production (ou)

> ....

The user 'Bart Syryn' (me) is member off the group users. When I check the password, then return-value = "". So everything is correct.

When I move the user 'Bart Syryn' to the group 'sales', then I get an error 49, invalid credentials. Our goal is to start looking for the user in the ou 'users', and look further in the tree, but that doesn't seem to work.

Another annoying thing is, that you have to use the 'display name' of the Active Directory and not the username. So I log on my computer with the user 'syryn.b', but when I want to use the winldapauth.p, the user must be 'Bart Syryn', because that's the display name in the Active Directory.

Many thanks for any help !!!

Regards

Bart Syryn

RUN "e:\openedge\authwp\WinLdapAuth.p" PERSISTENT SET m_hLDAPAuth

( INPUT "servername.coopman.be",

INPUT "",

INPUT "ou=coopman,dc=coopman,dc=be",

INPUT "",

INPUT "ou=coopman,dc=coopman,dc=be",

INPUT "",

INPUT "cn=Administrator,ou=coopman,dc=coopman,dc=be",

INPUT "passwordadministrator",

INPUT "-groups -attrs sn" ) NO-ERROR.

RUN authenticate IN m_hLDAPAuth ( INPUT "cn=Bart Syryn,ou=Users,ou=coopman,dc=coopman,dc=be",

INPUT "password Bart Syryn",

OUTPUT p_cRetAttrList,

OUTPUT p_cRetGroupList)

NO-ERROR.

IF ( "" = RETURN-VALUE ) THEN

MESSAGE "ok" SKIP p_cretgrouplist SKIP p_cretattrlist SKIP "ok" VIEW-AS ALERT-BOX.

ELSE

MESSAGE RETURN-VALUE SKIP "teste" VIEW-AS ALERT-BOX.

RUN finalize IN m_hLDAPAuth.

Bart,

While I'm looking at a couple of things, I may be able to help with you being annoyed. The sample uses a very generic search user search filter that looks for user accounts of objectClass "person" that has an attribute "cn" = or "uid" = . Since AD doesn't use the attribute "uid" very often, you search for the "cn" attribute which makes you login using your commonName (cn). What might be more specific to AD is the objectClass "user" and the login-id match for "cn" or "sAMAccountName" (which is the old NT domain user login name). You can modify the user account search by passing p_cUserSearchFilter (4th paramater) as:

"(&(objectclass=user)(|(cn=fflintstone)(sAMAccountName=fflintstone)))"

You can customize which login-id you want to use, or use multiples as in the example above.

You might add "-debug" to the p_cOptions parameter, and it will dump trace information to the output stream. It can dump a lot of useful debug information.

I'll get back to you with more on the search depth. In the meantime, your directory looks pretty simple, but are you using Aliases or Referrals by any chance?

Mike Jacobs

Bart,

I wanted to amend the LDAP search filter in the previous reply, the parameter you pass would be:

"(&(objectclass=user)(|(cn=%s)(sAMAccountName=%s)))"

What the sample implementation does is REPLACE the "%s" with the user's login-id that is passed to the internal procedure authenticate(p_cUserId, ...). In the previous reply, if the p_cUserId parameter was "fflitstone", then the example I gave you was the final LDAP search filter used by the code. You can choose one, or more, LDAP user account attribute names to allow the user to use in the login prompt. This example allows a match on the user account's cn OR sAMAccountName. You could add other OR'd (|) attribute names like (sn=%s) for logging in with their surname, dn (distinguish name), displayName, mail (e-mail), etc. The mapping of what what name, or names, to allow people to login with is what you want to support in your application and what the AD administrator enters into the user account attributes.

I hope this provides a better description of using the user search filters to allow different types of user login names.

Mike Jacobs

Hi Michael,

I've been playing with the new parameters you've provided, but I don't get the picture. I can't get it work, I will have to look deeper in it.

You don't have any news on searching the tree ?

I saw that the tree of OU's wasn't displayed correctly in the previous post :

coopman.b

....> coopman (ou)

.........> users (ou)

...............> finance (ou)

...............> sales (ou)

...............> production (ou)

...............> ....

Regards

Bart Syryn

In my configured AD, the sample works with multiple levels in the LDAP tree. But all AD configurations are not the same.

I'm going back over your code snippet and I notice some additional things.

In running the internal procedure authenticate, you are passing in the the user account's fully qualified DN. While you can do this, it is not typical that you require people to do that. More typical is allowing the user to log in (the first parameter) with the user-id as one of the account's attribute values such as "Bart Syryn". Then the sample will use the user-search-filter to find the account, get its fully qualified DN and then use it to validate the password.

I've modified your snippet to allow loggin in using the NT Domain account name (sAMAccountName) or the user account's commonName (cn). If from your previous post your NT account name is "syryn.b", then this user-search-filter should allow that to be used for the authenticate procedure's first parameter also. I'm also assuming that your test account password is not actually "password Bart Syryn", so make the password input case-sensitive. I also added the -debug to create an LDAPAuth.log with trace information. If you could mail that to me using my forum account, I would appreciate it.

If this still does not work, we will have to do some low level debugging to discover what the configuration differences are between your AD and mine. I suggest we take that off-forum at that time and I'll continue to help you.

OUTPUT TO LDAPAuth.log.

RUN "e:\openedge\authwp\WinLdapAuth.p" PERSISTENT SET m_hLDAPAuth

( INPUT "servername.coopman.be",

INPUT "",

INPUT "ou=coopman,dc=coopman,dc=be",

INPUT "(&(objectclass=person)(|(cn=%s)(sAMAccountName=%s)))",

INPUT "ou=coopman,dc=coopman,dc=be",

INPUT "",

INPUT "cn=Administrator,ou=coopman,dc=coopman,dc=be",

INPUT "passwordadministrator",

INPUT "-groups -attrs sn -debug" ) NO-ERROR.

RUN authenticate IN m_hLDAPAuth ( INPUT "Bart Syryn",

INPUT "password Bart Syryn",

OUTPUT p_cRetAttrList,

OUTPUT p_cRetGroupList) NO-ERROR.

IF ( "" = RETURN-VALUE ) THEN

MESSAGE "ok" SKIP p_cretgrouplist SKIP p_cretattrlist SKIP "ok" VIEW-AS ALERT-BOX.

ELSE

MESSAGE RETURN-VALUE SKIP "teste" VIEW-AS ALERT-BOX.

RUN finalize IN m_hLDAPAuth.

Hi Michael,

I've tried your snip of code, but it doesn't work. How can I reach you off topic. My email-adress is bart.syryn@coopman.be

Greetings

Many thanks Michael,

At last we got it worked out. Your snip of code worked well, I just didn't fill in all the correct parameters at our site.

At this moment we are testing it, and it looks like we are going to implement it in our application.

Regards

Can anyone post a link to the source code ? I cannot find it on PSDN for some reason.

Regards,

Etienne.

I think it refers to this:

http://www.psdn.com/library/entry!default.jspa?categoryID=1824&externalID=4587

Or use PSDN search: LDAP

Salvador,

Thanks for answering !

I get "The document specified was not found, or has expired." using your URL. I have already searched PSDN with "LDAP" and I see no article which has a download link for this LDAP code.

Etienne.

I'll check it out. Mean while I'm attaching the zip file with the document and the samples from that link.

HIH