Ldap, trusted mode and custom apps

[John Eaton]

Does anyone have experience with custom applications validating against HPUX trusted mode passwords, with LDAP?
We have an application that uses getprpwnam to lookup a users password and validate the password supplied matches. We want to convert to using LDAP to centralize our password management, as part of larger enterprise wide security/login process. The application fails to be able to validate the password when an LDAP user attempts to login.
I have written several simple programs using the getprpw... system calls, and they all still work, but they no longer return the encrypted password. These calls are nsswitch dependant, but none of them actully cause an LDAP lookup to occur.
We are using the latest LDAP-UX version, B.3.30, which provides trusted mode compatibility with LDAP, and have the latest LDAP (libpam) patch.
Any help would be appreciated.

[Steven E. Protter]

An actual error message would be useful here.

If you can identify the process id, you might be able to use tusc to gather information on the process.

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.7/

A sniffer like ethereal or tcpdump can also give you some idea whats going on.

http://hpux.connect.org.uk/hppd/hpux/Gtk/ethereal-0.9.15/

Right now you don't know whether the issue is networking, a switch configuration or an actual problem with the HP LDAP release.

SEP

[John Eaton]

Steven,
Thanks for your response, but there is no error, no failing process, or LDAP problem.
The application calls the system call getprpwnam, uses the first 2 characters of the u_pwd field for the crypt seed, crypts the supplied password and compares them.
When the user is from LDAP, not /etc/passwd, the getprpwnam system call returns '*' as the encrypted password. As i'm sure you know, nothing crypts to '*'.
The real question is about validating trusted system passwords for LDAP users from custom applications. The user can login to the server using the LDAP password, but can't login via the application for the reason noted above.
The getprwp... system calls use nsswitch to determine the order and source, but don't return the same info for an LDAP match vs a passwd (files) match. If the calls are really LDAP complient (as trusted mode is supposed to be at this version of LDAP-UX), why don't they do an LDAP lookup just like a login does? A login actually causes a call to the LDAP server, but using getprpwnam does not.
Proper use of the getprpw... system calls seems to be a well guarded secret from past experience, and maybe I've found another case of that.

[Steven E. Protter]

There are probably daemons or processes associaetd with the authentication. It should be possible to identify them and hang a tusc process on them and collect data.

Also, unless the LDAP server is on the HP box in question tcpdump or ethereal should collect data on the network traffic.

SEP

[Sundar_7]

Hi John,

I have only very limited experience on the LDAP products, but this is what I have found.

How is your LDAP-UX client configured to bind to your LDAP server ?

If "anonymous", for security reasons, LDAP server will not return anything for your getprprwent() queries.

Create a proxy user with ability to "search" and configure your LDAP-UX client to bind to the server using that user and give it a try again.

Let us know if this helps.

- Sundar.

[John Eaton]

Again,
Thanks for the replies, but I don't believe I'm making my point.
LDAP is -configured and working-. LDAP users can login fine. It's our custom application that is unable to validate LDAP users. It's a programmatic issue with the 'C' system call getprpwnam not using LDAP. I am confidant there is no issue with the LDAP configuration.
Am I making a false assumption that the trusted system calls (getprpw...) are not LDAP compliant, even though trusted mode is supposed to be LDAP compliant? (rhetorical question, unless someone has the answer)
I'm interested in responses related to programing use of LDAP on a trusted system.

[Ron Luman_1 · Accepted solution]

Hi John,

In short: Yes, your assumption that the getprpw* calls are actually 'nsswitchified' is incorrect. The latest version of LDAP-UX doesn't actually provide full backends for the prpw APIs, which would require defining new (HP-specific) schemas for the trusted mode account and password policy information.

Instead, the latest update allows the _co-existence_ of LDAP and TM. Essentially allowing them to be used at the same time. In order for this to work, and to support auditing LDAP users, the (local) TCB entries for LDAP users are created 'on-the-fly' at login time. The dynamically created entries only contain the minimal information to make existing commands and libraries continue to function. Specific to your situation, the password stored in the dynamically created TCB entry (and returned by your calls to getprpw{uid|nam|ent} is the fixed string "*". The end result is that entries in the TCB created for LDAP users will not allow authentication. Instead, it is expected that authentication occurs via PAM which will go down the pam_ldap path after the pam_unix->getprpwnam() auth fails.

Without knowing much about your application, I would recommend using PAM rather than directly checking the password in your application.


Hope this helps,

--Ron

[John Eaton]

Ron,
Thanks for the great answer. I suspected a situation like this may have been the case. I did notice that the TCB entries were being created after the first login.
FYI, I did not assume that getprpw... calls are nsswitchified, it states so in the man page:
"Additionally, all of these routines depend on the configuration of the Name Service Switch file, /etc/nsswitch.conf."
This response pretty well closes out the issue, but I'll leave the thread open a little longer.
Thanks,
John

[John Eaton]

One more thing...
Any idea where I can find further details on how to continue on (beyond getprpwnam) and authenticate with pam_ldap, progamatically?
Thanks!

[Ron Luman_1]

Hi John,

Regarding the use of PAM, there are manpages that describe the interfaces (all linked off of pam(3)), but they're more of a reference than a guide on using the APIs.

I, personally, have found the Linux-PAM Application Developer's Guide to be a reasonable primer: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl.html. Note that there are slight differences between HP-UX PAM and Linux PAM, but they're close enough for most purposes. (PAM is an OpenGroup standard.) The major differences lie in a few helper routines that Linux provides that HP-UX does not.

As for writing to pam vs. pam_ldap: The intent is that your application use PAM, which abstracts away all the details of which actual module PAM is configured to use. If you want to ensure that your application only ever interfaces with the directory, then you can make sure that the pam.conf contains an entry specific to your application only calling out to LDAP.

Cheers,

--Ron