Linux : - How to check getpwnam() is working on the system or not ?

[rveri-admin]

Hi Experts,

After a batch job agent has been installed on the linux system,  the batch team said the job failing due to not able to do the authentication.

The authentication is being used is LDAP authentication.

Also said that the batch job software articale said to check if  getpwnam() is working on the system.

Question is how to check getpwnam() , this looks like a C program function.

# Man command gives following output:

$ man -k getpwnam
getpwnam             (3)  - get password file entry
getpwnam             (3p)  - search user database for a name
getpwnam_r [getpwnam] (3)  - get password file entry
getpwnam_r [getpwnam] (3p)  - search user database for a name
getpwuid [getpwnam]  (3)  - get password file entry
getpwuid_r [getpwnam] (3)  - get password file entry

Thanks for the help..

[rveri-admin]

Any update... 

Seems to be any one with C programming knowledge can help,  since the function looks like a C function  getpwnam ().

Thanks,

[Matti_Kurkela]

The C function is very likely what the batch job software article refers to.

In Linux, the "getent" command is probably the closest command-line equivalent to the getpwnam() function.

For example, if we know that the user "ldapuser" has his/her user information stored in LDAP, the command

getent passwd ldapuser

 ...should return a line formatted just like a /etc/passwd line, but containing the user information stored in LDAP, if the LDAP username resolution is properly configured.

At least on my Debian 6.0 system, the EXAMPLES section of "man 3 getpwnam" includes a short C program that demonstrates how to test the getpwnam() function (or rather, the getpwnam_r() version of it).

With LDAP-based authentication, the situation is somewhat complicated by the fact that LDAP-based authentication and LDAP-based username lookup are not always handled by the same mechanism.

The LDAP authentication is handled by the PAM module pam_ldap, which does it using the normal LDAP authentication procedure: it asks the username & password from the user, then searches the LDAP directory for the appropriate entry and makes a LDAP bind request. The LDAP server checks the password, and reports either success or failure. (Note that the client never needs to receive the password hash stored in the LDAP directory.)

On the other hand, LDAP-based username lookup works via nss_ldap library, which is used when the passwd: line in /etc/nsswitch.conf includes the keyword "ldap". It searches for the appropriate information in the LDAP directory, and constructs the appropriate responses to match the traditional Unix APIs like the expected output of getpwnam().

If your batch job agent is not PAM-aware, and it attempts to do password authentication in the "grand old Unix" way, this might present a problem. The old (pre-PAM, pre-shadow) Unix way of handling password authentication assumes that any program can get the password hash from the /etc/passwd file and compare it to the password that is received from the user and passed through the appropriate hash algorithm.

With LDAP, there are several issues in this:

1. With most Linux systems, the passwords are not stored in /etc/passwd, and the password field returned by getpwnam() contains a simple "x" placeholder. The program would need to use getspnam() instead to fetch the password hash from /etc/shadow... and it would need to be running as root or at least setgid shadow, or it won't be allowed to do that. LDAP can implement this restriction too.
2. With native LDAP authentication, the client only needs to be able to authenticate against the password stored in LDAP and change the password record. So the LDAP directory may be configured to allow those operations only: allowing the applications to read the password hash from the LDAP directory is strictly optional (and in fact not recommended if maximum security is desired).
3. Even if reading the password hash is allowed, LDAP allows storing the password hash in formats that are not compatible with any password hash format that is used in /etc/passwd and /etc/shadow entries. So even if the program could receive the password hash, it might be stored in a non-traditional format that is useless to a non-LDAP-aware program.

All these three points can be avoided by appropriate configuration of the LDAP server.

But it would be so much simpler if your batch job agent would use PAM for authentication: you would just have to make sure that the PAM configuration file of the batch job agent in /etc/pam.d/ directory contains the appropriate pam_ldap.so entries (like any other services that want to use LDAP for authentication).

[rveri-admin]

Mk,
Thanks much for the details explanation:

The ldap entry is there in the /etc/nsswitch.conf :


$ cat /etc/nsswitch.conf | grep -i ldap
#passwd: files ldap
#shadow: files ldap
group: files ldap
passwd_compat: ldap
shadow_compat: ldap
netmasks: files ldap
networks: files ldap
netgroup: files ldap
automount: files ldap
$


The batch agent is ActiveBatch agent and still trying to understand what you have mentioned with regard to /etc/pam.d/ as there is no pam_ldap.so files or entries.

Thank you.

[Matti_Kurkela]

Ah, so your configuration uses LDAP as a replacement for NIS (the _compat entries), instead of using native LDAP authentication with the pam_ldap PAM module. It might not be the preferred way to set up LDAP-based authentication, but it might be needed in some situations.

So far you haven't mentioned one important basic fact:

What is the name and version of your Linux distribution?

You probably have at least one line in /etc/passwd that starts with the "+" character. If the ActiveBatch agent is not using PAM and is programmed to assume traditional cross-platform Unix practices, it might be assuming that you're using NIS instead of LDAP and doing the wrong thing because of that.

If your ActiveBatch agent is the product of http://www.advsyscon.com then there does not seem to be any proper technical documentation available without registration.

Things to test:

Find a user account that is definitely stored in LDAP only (i.e. there is no local copy of the user's information in /etc/passwd & /etc/shadow). I assume here that such a user has username "ldapuser": replace it with the username of a suitable user in your environment.

Run "getent passwd ldapuser" as any user: it should return the UID, primary GID, real name, home directory and shell settings of the user, formatted just like a standard /etc/passwd line, even if the user information is stored in LDAP. Does it return the expected values?

(If this does not work, it means the nss_ldap module fails to get the information from the LDAP directory server. This problem needs to be fixed before any further testing.)

Then run "getent shadow ldapuser" as root: it should return the user's password hash and password expiration information, formatted just like a line in /etc/shadow. Is the password hash in the right format?

(There are several possible outcomes here:

1. your Linux distribution might not support "getent shadow", resulting in an error message.
2. there might also be a problem with the rootbinddn setting in the LDAP client configuration, or with the ldap.secret file. This might produce a different error message, or simply no output at all.
3. the permissions of the LDAP directory might not allow the password hash to be read at all, so the password hash field will most likely contain only some placeholder. This would mean the directory server is configured to expect pam_ldap style configuration instead of your NIS-compatibility style.
4. the password hash might be readable, but stored in a format that is not convertible to the format expected in /etc/shadow. In this case, the "getent shadow ldapuser" output might include a placeholder or a password hash field that is neither correct size for the traditional Unix crypt() nor contain the "$<number>[letter]$" prefix identifier for the advanced /etc/shadow password hash algorithms.
5. the best case is that the getent command will return a valid password hash for the LDAP-based user.)

[Babula]

In my case I find getpwnam_r was able to  read user detail from Active Directory.  This I could find using both wireshark and strace. In both the tools I can see, Acrtive Directory  has returned the values but getpwnam_r returns NULL in my program.  I find username , uid, gid and other stuff was received by getpwnam_r. Any clue what could be the problem.