Looking up users via username _or_ other attribute?

[Erik Forsberg-9]

Hi!

Can nss_ldap be configured to search for user entries with a filter that
looks for the supplied username in multiple attributes? For example,
when I do 'getent passwd test', I would like nss_ldap to query the LDAP
server for
'(&(objectclass=posixAccount)(|(uid=test)(otherAttribute=test)))'

The reason behind this would be to allow authenticating using a
mail address, certificate serial number or some other information stored
in LDAP against openssh's sshd, which runs a
getpwent(username-sent-over-network) to decide if a user is valid or
not, while still keeping the real username in the environment.

I could set 'nss_map_attribute uid mail', but all users
would then be listed with that attribute when listing file/process
ownership. Also, it would be nice if I could have some users logging in
via their mail address, and some via their username.

Regards,
\EF
--
Erik Forsberg                OpenSource-based Thin Client Technology
Systems Analyst/Developer    Phone: [phone]    
Cendio AB                 Web: http://www.cendio.com

[Matthew Hardin]

Hi Erik,

Erik Forsberg wrote:
> Hi!
>
> Can nss_ldap be configured to search for user entries with a filter that
> looks for the supplied username in multiple attributes? For example,
> when I do 'getent passwd test', I would like nss_ldap to query the LDAP
> server for
> '(&(objectclass=posixAccount)(|(uid=test)(otherAttribute=test)))'
>
>  
The nss subsystem doesn't work quite like that, but reading on, I see
that you are really asking a different question.
> The reason behind this would be to allow authenticating using a
> mail address, certificate serial number or some other information stored
> in LDAP against openssh's sshd, which runs a
> getpwent(username-sent-over-network) to decide if a user is valid or
> not, while still keeping the real username in the environment.
>  
> I could set 'nss_map_attribute uid mail', but all users
> would then be listed with that attribute when listing file/process
> ownership.
You are correct that using nss_map_attribute would not accomplish what
you want.

Although possible, it is considered poor security design to rely on the
NSS subsystem for user authentication, as this mandates hashed passwords
stored in LDAP using the weak 'crypt' format. There are a number of
other deficiencies in this design that are outside the scope of this
discussion. Suffice it to say that you should use nss_ldap in the way it
does best: returning tabular information from a datastore for tasks such
as translating between textual and numeric user ids. This would meet
your goal of 'keeping the real username in the environment'.

The PAM subsystem has taken over the authentication functions in most
modern UNIX- and Linux-based operating systems. In LDAP-based
authentication the pam_ldap module is used to authenticate users in a
secure fashion. The most popular pam_ldap module is from PADL, and since
you're posting here I presume that's the software you're using. This
module allows you to select an arbitrary attribute to be used in
determining which user object to use as a basis for authenticating. In
PADL's pam_ldap module this is the pam_login_attribute parameter in the
ldap.conf file. Set this parameter to the name of the attribute you want
to use. For example, set it to 'uid' if you want to authenticate based
on the contents of the 'uid' attribute in the directory. You could also
use another attribute, such as one that contained a user's email
address, social security number, etc.
> Also, it would be nice if I could have some users logging in
> via their mail address, and some via their username.
>  
As currently written, the configuration file format for pam_ldap
(usually /etc/ldap.conf) allows you to choose one attribute for pam_ldap
to use in looking up a user. That being said, individual services in the
PAM configuration file (/etc/pam.conf) can specify different pam_ldap
configuration files, so it's conceivable that you could come up with a
pam.conf file the specified different pam_ldap configuration files for
sshd, telnet, and login. Each of these configuration files could then
list its own attribute a user would need to use for identifying herself.

You'll need to refer to the man pages for PADL's nss_ldap and pam_ldap
for additional information, but hopefully this will get you pointed in
the right direction.
> Regards,
> \EF
>  
Cheers,

-Matt

--

Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com

[Erik Forsberg-9]

On Sat, 19 Jan 2008 11:13:38 -0700
Matthew Hardin <mhardin@...> wrote:

> Hi Erik,

Hi, and thanks for your reply. Sorry about my delay in replying, got a
lot of other projects going on.

> Although possible, it is considered poor security design to rely on
> the NSS subsystem for user authentication, as this mandates hashed
> passwords stored in LDAP using the weak 'crypt' format. There are a
> number of other deficiencies in this design that are outside the
> scope of this discussion. Suffice it to say that you should use
> nss_ldap in the way it does best: returning tabular information from
> a datastore for tasks such as translating between textual and numeric
> user ids. This would meet your goal of 'keeping the real username in
> the environment'.

Well, I do not want to use the crypted passwords stored in LDAP - what
I want is to map one kind of username into another kind of username at
login.

The reason for this is that I want to login with a public ssh key, but
on the client side, I only know a certificate subject on the form
C=SE,CN=My Name,GN=Some other Name/serialNumber=YYYYMMDDNNNN, not the
username. On the server side, I can, via LDAP, map the certificate
subject into a username.

Unfortunately, it seems like openssh is not built to support this
function - it makes a getpwnam on the username sent by the ssh client,
which will fail. I guess the correct way of doing this is to try to
authenticate via PAM first, then extract PAM_USER from the PAM library
and use that to find out where the user's home directory etc. resides.

Another way of getting the same result would be to make nss_ldap find
the user for us by configuring it to find a user entry based on a
configurable filter, not based on a fixed filter that only checks one
attribute.

> As currently written, the configuration file format for pam_ldap
> (usually /etc/ldap.conf) allows you to choose one attribute for
> pam_ldap to use in looking up a user. That being said, individual
> services in the PAM configuration file (/etc/pam.conf) can specify
> different pam_ldap configuration files,

Oh, this is news to me - where can I find out the exact syntax? I don't
think it solves this problem, but it would be interesting to know. Can
I also specify different nss_ldap configuration files, that way
fetching usernames from several LDAP servers, or from the same LDAP
server but with different configuration?

nss_ldap(5) on a Fedora Core 7 says:

       nss_ldap  stores  its configuration in the ldap.conf file, the
location of which is configurable at compile time.

Regards,
\EF
--
Erik Forsberg                OpenSource-based Thin Client Technology
Systems Analyst/Developer    Phone: [phone]    
Cendio AB                 Web: http://www.cendio.com