i’ve been searching for hours now and still didn’t find a solution to my problem:
I successfully configured the LDAP Client on a SLES 11 SP2 for VMWare machine and can authenticate against our Windows Server 2008 R2 Domain. What I want is to login with the userprincipalname instead of the samaccountname.
I tried to change a few settings in ldap.conf, but that doesn’t seem to change anything. I can successfully login with “domain\username”. But I want to login with username@domain.com which would be the UPN attribute.
Where can I change the mapping? Here is a part of my ldap.conf where i tried to change the mapping (which obviously didn’t work):
# RFC 2307 (AD) mappings
#nss_map_objectclass posixAccount user
#nss_map_objectclass shadowAccount user
nss_map_attribute uid userPrincipalName
#nss_map_attribute homeDirectory unixHomeDirectory
#nss_map_attribute shadowLastChange pwdLastSet
#nss_map_objectclass posixGroup group
#nss_map_attribute uniqueMember member
pam_login_attribute userPrincipalName
#pam_filter objectclass=User
#pam_password ad
Anything showing up on the LDAP server in the logs/traces that would
indicate why it’s not working? I assume since sAMAccountName works the
connection is happening properly and everything else is configured
properly. I don’t have a MAD server around to check on things but I
assume UPN is something that can be accessed anonymously (without
authentication) like sAMAccountName, but if not that may be an issue.
If this was something like eDirectory’s LDAP interface I’d check the
trace from the server to see what was passed in and then sent back to
the client, but other than a LAN trace with tcpdump (or similar) I’m not
sure how to do that in with MAD.
What do you get (if anything) in /var/log/messages or the like during
the authentication attempt?
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
Hi,
here is the output from var/log/messages when i try to login with upn:
sshd[4382]: Invalid user xxx@xxx.com from 192.168.xxx.xxx
sshd[4382]: error: PAM: User not known to the underlying authentication module for illegal user xxx@xxx.com from xxx
sshd[4382]: Failed keyboard-interactive/pam for invalid user xxx@.com from 192.168.xxx.xxx port 49516 ssh2
So if this worked using sAMAccountName why didn’t the search work with
the other attribute? That’s the question that comes to my mind, anyway.
What does the server side show for this query compared to the previous
one that did work for sAMAccountName?
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/