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?  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 don’t know how to search in one shot given just  samaccountname and passwd.

 

The other topic is security:  I was intending to invoke the ldapsearch from inside the Apache/Webspeed/Progress/ABL application as a "input-output through", meaning we run this and read/write its STDIn/StdOut.    Since Progress ABL is an interpreted DB language this makes some sense.    It also provides portability between Linux and Solaris that we don’t have if we try to call the shared C libraries.   And the C libraries calls are locking up.    Best practices would indicate we'd want to hide the passwords.    We don't want some administrator doing a 'top' command seeing passwords.  Unfortunately, this does not seem readily possible without jumping through hoops.

 

The openldap ldapsearch has a -W option to prompt for passwd, but that appears to not read StdIn, but rather /dev/tty.   So I cannot feed it passwords that way.

 

There is a "-f" option, which offers a - flavor to read StdIn, but I don't see any examples of what the input to -f looks like, eg: can I specify password there.

There is a -y option to specify a file which contains the password.   ok, I could write the file, put it somewhere not readable by anybody but Apache, run ldapsearch, and then delete the file.    Still, that doesn't smell like best practices to me.    Today I tried making the file a named pipe; that also works if I get the timing just right.   I guess I could do that if there isn’t a better way.

So, it seems like either I'm missing something or the use of ldapsearch for password validation opens up holes and less than best practices.    Yes, I could dork around with calling shared libraries, and then fight that portability battle between linux and Solaris.   Why is it so hard?

For a contents, this is a low volume, probably 200-400 people, one time in the morning, each day.

 

Neal Rhodes | Software Engineer - REALServicing® Development

Altisource™
P: (770)933-6625 extension 256625  F: (770)644-7420

Neal.Rhodes@altisource.com| www.altisource.com

 

Progress and Enterprise RDBMS OpenEdge are trademarks or registered trademarks of Progress Software Corporation in the U.S. and other countries. Citrix, GoToAssist, GoToMeeting, GoToMyPC, GoToTraining, GoToWebinar, Podio and Sharefile are trademarks of Citrix Systems, Inc. or a subsidiary thereof, and are or may be registered in the U.S. Patent and Trademark Office and other countries. Windows is a registered trademark of Microsoft Corporation in the United States and other countries. Any other trademarks contained herein are the property of their respective owners.