Rhodes, Neal A wrote:
So, I'm trying to implement a login running inside Webspeed inside Apache inside linux. There are good reasons to do this inside this application program and not just let Apache do it. (inactivity timeouts, daily quotas, IP reasonability, etc)
So, what I get from user is network-user-id (let's call him "bob") and password.
What I need to know is:
Does this userid exist (samaccountname=%s), is the password provided correct? if above is good, is this user memberof a specific group?
What I've got working as proof-of-concept is:
A. Do a simple bind to LDAP with an admin/service account as a DN, and search for this user-id (samaccountname=bob), and get back the DN for user "bob". Using $OpenLDAP: ldapsearch 2.4.39
/ldapsearch -v -d 0 -P 3 -D "CN=rslXXXXXXXreq,OU=Service Accou DC=com" -w "XXXXXXXX" -oldif-wrap=no -s sub '(&(objectclass=*)(samaccountname=rhodesne))' cn userAccountControl objectclass userPrincipalName
/B. Then do ANOTHER simple bind to LDAP using "bob"s as DN, and "bob"s password, and return the memberof attribute. That fails if I don't give it the correct password.
/ldapsearch -P 3 -D "CN=Rhodes, Neal A,OU= C=COM" w BobsPasswd -oldif-wrap=no -s sub '(&(objectclass=*)(samaccountname=rhodesne))' cn userAccountControl objectclass memberOf userPrincipalName manager/
OK, it works. I can walk through the results and confirm that Bob is in a desired group. I don't claim to know LDAP; but isn't this convoluted?
Searching with a service account and then Binding with the returned DN is the standard method for applications to authenticate users who only login with a simple username (as opposed to providing their actual DN).
Is
there a way to do this in one shot with the ldapsearch command? I can do it this way, but it seems clunky. I dont know how to search in one shot given just /samaccountname and passwd. /
No, there's no one-shot approach unless you control the backing LDAP server, know that all user entries live under a specific location in the DIT, and know that the user's simple name is part of the entry's DN. In that case you can skip the search and just perform the Bind using your knowledge of the DN format. But you still have to use a separate step to verify group membership.
Your check for group membership is nonstandard/wrong. The correct method is to use LDAP Compare and check if the group of interest's set of members includes the user's DN.
e.g. ldapcompare "cn=some group,ou=groups,dc=example,dc=com" "member:cn=Rhodes, Neal A,ou=people,dc=example,dc=com"