pam_authz case sensitivity problem with kerberos and AD

[Tony Horton]

I have a problem with a lot of users in AD who have been migrated from Novel having upper case userid's in AD.

environment is 11i V1 with the Dec 2009 quality pack installed and the following versions of software:

B8725AA_A.02.04a_HP-UX_B.11.11_32_64.depot
KRB5CLIENT_C.1.3.5.10_HP-UX_B.11.11_32_64.depot
OpenSSL_A.00.09.08n.010_HP-UX_B.11.11_32_64.depot
PAMKerberos_B.11.11.17_HP-UX_B.11.11_32_64.depot
T1471AA_A.05.50.013_HP-UX_B.11.11_32_64.depot


ldap (interactive) login using lowercase name works fine. Pam_authz matches users to groups (including those in LDAP) with no problems.

When someone logs in with Kerberos, if the user is defined in AD with upper case then putty sends an Upper Case username. If the users primary group is listed in pam_authz.policy as allowed to login then they can login. If only a secondary group that is in the pam_authz.policy then they fail to login.

Debugging output shows that Pam_Authz is doing a comparison of the username to the members of the group. Group members are allways lowercase (even when coming from AD and the user is uppercase in AD). If the userid passed in via gssapi is uppercase pam_authz fails to match, and the user can't login.

If the group is the primary group, it seems it just matches on the fact that the user has the right GID and doesn't do a string comparison and the user is able to successfully login.

I tried using the netgroup_case_ignore=1 line but it didn't help (was a long shot).

What I don't know is if this is a bug, or normal behaviour. I can as a workaround change all users from uppercase to lower case, but this is about 800 users so would prefer not to if possible.

an example might help.

Say Joe is defined in AD as JOE

Joe's primary group is group1 and he is also a member of group2

in pam_authz.policy is a line

allow:unix_group:group2

group1 is not in pam_authz.policy

if Joe logs in via interactive login he is able to login successfully. However if he logs in via kerberos his login fails. When debugging is enabled it will show the following:
PAM_AUTHZ: Checking Unix group group1
PAM_AUTHZ: unix_group cmp JOE to joe
Failed gssapi-with-mic for JOE from .....

If group1 (joe's primary group) is added to the allow list in pam_authz.policy then Joe can login via kerberos without issue.

So, is there a setting that I can change to make this work, should I be reporting it is a bug, or should I just accept it and change everyone to lowercase in AD?

It seems that the pam_authz module is doing things in a very roundabout way, in that it checks every member of every group against the current userid until it finds a match. Surely it would be more sensible to return the list of groups the person was a member of and see if any of them match the groups allowed in the pam_authz.policy file.... This would remove the whole case sensitivity issue!

Tony.

[Don Mallory]

Hi Tony,

I think there are a couple of things going on.

First, yes, there would be benefit to report the issue to HP Support, and hopefully a fix / patch be added to the pam_authz module in the future. It is however doubtful that there is an obvious workaround.

I do agree that it would be better if it returned a similar output of "id" and just compared to membership, but that's not how they wrote it. (Oh well...)

Yes, I agree that it would be benefial to change the case of all the users, but that's frustrating at best. Windows is known for being case insensitive, and UX is of course, the opposite, so if you plan on continuing a lot of integration, it's better all-around.

What I'm most curious about is that you note that an interactive login. I'm assuming ssh, manual acocunt name and password entry, not key-based auth, or do you mean by telnet? Is the user enterring the username in uppercase during the interactive login, or lowercase?

Is the pam_authz being used for all types of activity, not just sshd logins?

In my environment, I have designated a global AD-based group per host to manage authorization. This group is has the SFU entries and is in the pam_authz.policy on the local host. Needing to have that as the primary group would never work for all the users.

Best regards,
Don

[Tony Horton]

Hi Don, If the user has no public key (and is not using a kerberised putty) then they are as per normal prompted for userid and then password when doing an ssh login. If they type in the userid in lower case then the password they login successfully.

I think the main issue is that when logging in using gssapi the username must match the case in AD or the gssapi fails, as I believe kerberos is case sensitive.

For instance, if I try to login via kerberised putty but set the username manually in putty to not match the case of the username I'm logged into AD with then the kerberos portion fails and I get prompted for password. If my AD was uppercase and I forced lowercase then I will be able to login after putting in the password, but the main point of the kerberos is to enable the single signon :)

The kerberised putty will pick up the upper case username from windows automatically and uses that during the gssapi exchange.

I don't think that the problem is related to kerberos as such, as the same problem happens if I login using a non kerberised putty and put the username in in upper case (ie if the primary group is in pam_authz.policy then they can login, but if only a secondary group is there, they cannot).

Pam_authz is being used for most things and is first entry required (exceptions are su and rcmds)

regards,

Tony.

[Don Mallory]

Hi Tony,

If the source client is deciding whether or not to use a Kerberized connection, then I would suspect you are not using the UsePAM yes option in your sshd_config, which means you are probably not managing this with PAM, but with the full GSSAPI subystem in sshd...

Yes, Kerberos is case sensitive. It likes uppercase for realms, but otherwise, all it fully case sensitive.

Although I'm not sure it would help, would you mind posting your sshd_config? I'm curious as to how you implemented differently than I did. It may help other forum members comment on a possible solution, but I don't think there is one, except for the hard route.

It sounds like something is not respecting the case properly, whether it's the AD reporting it incorrectly in the query response for the gruop memembership, or how pam_authz is dealing with it, I don't know.

Have you tried contacting HP Support? Once you get through the first couple of levels, there are a couple of really gifted Kerberos experts on the backline. I share the same given name with one of them, if you get him, you are sure to find a solution.

Best regards,
Don

[Tony Horton]

Hi Don,

I've found out why it bombs out (thanks Greg :) ) . We initially changed over to using ldap for authentication (promting for userid and password) and a large number of users were logging in using telnet. As you would know logging in with an uppercase userid in telnet is problematic, and to get around the problem the UID field (in AD) for the users was changed to the username in lowercase using adsiedit. I'm not sure why we weren't just changing the case of the userid in AD (perhaps resistance from the AD guys...) so changing UID it was. As it turns out, ldap lookups use this UID field which is in lowercase, and Kerberos lookups use a different field (which is in uppercase). This has been working fine up until now. If I change the UID field back to uppercase in AD then pam_authz works properly for any AD groups, but bombs on any local unix groups unless the user is in that group in upper case.

Anyway it does look like the solution is to change the username in AD, we could just leave the UID uppercase, but then local unix groups need the user in upper case, and I'd rather have everything consistent!

Here is what is in the sshd_config, most of the comments removed to make it easier to see what is not default.

# $OpenBSD: sshd_config,v 2.00 2008/07/29 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/ssh/bin

#Port 22
Protocol 1,2

SyslogFacility LOCAL6

# Authentication:

# Auth selection

# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
UsePAM yes

X11Forwarding yes
X11UseLocalhost yes
PermitUserEnvironment yes

# override default of no subsystems
Subsystem sftp /opt/ssh/libexec/sftp-server

UseLogin no
LogLevel VERBOSE
UseDNS no
AcceptEnv a_few_env_variables_removed

I hadn't raised a call (specifically about this) yet with support because I didn't have the latest LDAP-UX integration version installed, and felt I should do that before raising a call. I rasied a support call about that because only 11iv2 and v3 are available for download, and eventually after talking to our account rep managed to get the V1 lastest version (yet to be installed).

I know what you mean about getting past the initial people, I have over the years only raised a few calls, and always had to go to the top level guys, as if I am raising a call, it means I'm REALY stuck ;) Always has been a pleasure working with them once I get their but the getting there is a lot harder than it used to be.

Cheers,

Tony.

[Don Mallory]

Hi Tony,

That's great to hear that you were able to narrow down the issue. Now that you mention the tweak of the case of the UID vs samAccountName entires in AD, that makes perfect sense (as hindsight usually does. :-)

I also see some of the difference you are using for your sshd config. Here is mine, removing comments:

Protocol 2
LoginGraceTime 90
PermitRootLogin no

PasswordAuthentication yes
KerberosAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes

X11Forwarding yes
X11UseLocalhost no

Banner /etc/issue
HPNDisabled yes
Subsystem sftp /opt/ssh/libexec/sftp-server

Our big difference is that I'm using PAM entirely for the Kerberos auth, where you are also doing it natively in the sshd daemon.

Just a word of caution about your config, you should disable ssh v1 if possible in your environment. The protocol has been known to be broken for a few years now.

Don

[Bob Neal-Joslin]

The behavior of pam_authz, though strange, is as intended. pam_authz must handle unix_group membership this way for a few reasons. First, the unix_group rule is defined to use the getgrnam() API to identify group membership. The purpose for using this API is to allow more than just LDAP-based group membership. getgrnam() supports different backend group naming services including /etc/group, NIS and LDAP. And Unix defines that group names are case sensitive. So after retrieving the group, pam_authz does a case-sensative comparison to be compatible with the Unix specification. Unfortunately, the Unix specification and RFC2307 specification clash, regarding the case-sensitivity issue. And your experience is one side-effect.

Your question as to why primary group membership affects this result, there is a reason for that as well. With Unix, it is possible to be assigned a primary group, but not be explicitly listed as a member of that group. Membership in this case is implied by being assigned as a primary group member. In order for pam_authz to properly determine group membership, it must perform two checks, first see if the group is a primary group, and if not, then check to see if the user is listed as a member of that group. When checking primary group membership, the group number from the user's account is used to identify the group name, and that is compared against the one listed in the rule.

As to your question about why pam_authz does not just search for all groups the user is a member of, and then check that list; the unix_group command was designed to support all name services supported by the getgrnam() API. Using that method would exclude other (non LDAP) name service repositories. On the other hand, using the ldap_group rule will work more how you desire, ignoring case, as would be expected for LDAP based groups (since LDAP groups are based on DN based membership attributes).

Sorry that's not the answer your looking for. I hope it is not too much trouble to either change the case, or switch to the ldap_group rule instead.