So, some Solaris updates
24 06 2009Some minor updates on the Solaris/AD front. Alex and I have opened tickets with both Microsoft and Sun regarding the problems we’re seeing with VLV support between Solaris and Active Directory. Based on conversations and emails with both companies, we don’t think it’s VLV that’s really broken. Along with VLV, it appears you have to/should implement RFC 2891. What’s RFC 2891 you ask?
“LDAP Control Extension for Server Side Sorting of Search Results”. Also known as SSS.
This function allows the client to tell the server to sort the returned results on some key. The RFC states that the controlling commands that you pass to the server must contain at least one key. But it doesn’t say it must contain only one key. After some pointed searching, Alex was able to find a knowledge base article discussing SSS and how it is implemented on the Active Directory domain controllers. Microsoft has chosen to interpret the RFC as “No, really, we only have to support one, therefore, we’re only going to support one.” That’s what we both inferred from their article.
Sun basically came back and said what we already know: disable VLV on the domain controllers. There’s a hotfix to do this, but it has bad performance impact on Outlook Web Access. Though, now I have to wonder about it because Microsoft made the claim that VLV actually slows things down while on a conference call today. What the heck?! We’re trying to get more clarification on that.
So, we have a good working theory now and the packet captures seem to support it. The Solaris client is throwing two attributes back at AD to sort against: cn and uid. But, AD seems to be kicking back. Hmm. Now that I think about it, I don’t really understand why cn is being used in the sort list. We’re just calling it to fill out gecos information. The only place we reference that in the ldap configuration on the client is to map the GECOS information. I need to do some packet captures and see what happens when I remove that.
In other news, I have done some more work on the Solaris client configuration after somehow managing to break it (again). Before I get too far away from what works, I’ll go ahead and post it here.
# login service (explicit because of pam_dial_auth) # login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth sufficient pam_unix_cred.so.1 login auth sufficient pam_unix_auth.so.1 login auth sufficient pam_krb5.so.1 # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authentication # other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_unix_cred.so.1 other auth required pam_unix_auth.so.1 # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account sufficient pam_ldap.so.1 other account required pam_list.so.1 allow=/etc/user.allow debug
So, what we have here is a PAM configuration that _should_ allow a local user (such as root) or an LDAP user to login to the console. Yes, being able to login as root is important and that was part of my previous breakage that I hadn’t noticed.
The other two pieces, “other account” and “other auth” handle all other services not explicitly named. The auth one is basically the same as the login. The account configuration is special. You’ll see two new PAM modules here: pam_ldap and pam_list. pam_ldap tells PAM to go query against LDAP whenever trying to find account information. I’m not quite sure how it ties into the nsswitch.conf configuration for passwd and group. This was just the recommendation so I went with it.
The pam_list setup is my attempt at mimicking pam_access on Linux. This half works. You should be able to put netgroups into the /etc/user.allow file but because of the VLV/SSS interaction between AD and Solaris, this doesn’t actually query anything useful in LDAP. Herein lies a big problem: I have authentication of my users, but no manageable way to deal with authorization. This is important for some of our customers who need to lock down exactly who can get access to a system once authenticated.
Bummer.
Solving this will require one of three options:
- Microsoft fixes SSS to allow more than one sort key.
- Sun fixes Solaris to allow the client to ignore the VLV support on a server. Not likely unless you’re willing to get your account manager to put an RFE in (or pay for it)
- Run a Microsoft ADAM, mirror your entire AD structure into it, and then turn off VLV support on the ADAM.
So what else is required? We need the ldapclient configuration. Solaris uses a configuration tool to handle this, unlike Linux where you just edit the config file. Solaris builds a config file for you but cautions you to never edit it.
ldapclient manual \ -a credentialLevel=proxy \ -a authenticationMethod=simple \ -a proxyDN=binduser \ -a proxyPassword='binduserpassword' \ -a defaultSearchBase=dc=austin,dc=utexas,dc=edu \ -a domainName=austin.utexas.edu \ -a defaultServerList="AD domaincontroller IP address" \ -a followReferrals=false \ -a attributeMap=group:userpassword=userPassword \ -a attributeMap=group:memberuid=memberUid \ -a attributeMap=group:gidnumber=gidNumber \ -a attributeMap=passwd:uid=sAMAccountName \ -a attributeMap=passwd:gecos=cn \ -a attributeMap=passwd:gidnumber=gidNumber \ -a attributeMap=passwd:uidnumber=uidNumber \ -a attributeMap=passwd:homedirectory=unixHomeDirectory \ -a attributeMap=passwd:loginshell=loginShell \ -a objectClassMap=group:posixGroup=group \ -a objectClassMap=passwd:posixAccount=user \ -a objectClassMap=shadow:shadowAccount=user \ -a serviceSearchDescriptor='passwd:dc=austin,dc=utexas,dc=edu?sub?uidNumber=*' \ -a serviceSearchDescriptor='shadow:dc=austin,dc=utexas,dc=edu?sub' \ -a serviceSearchDescriptor='user_attr:dc=austin,dc=utexas,dc=edu?sub' \ -a serviceSearchDescriptor='audit_user:dc=austin,dc=utexas,dc=edu?sub' \ -a serviceSearchDescriptor='group:ou=Departments,dc=austin,dc=utexas,dc=edu?sub?gidNumber=*' \ -a serviceSearchDescriptor='netgroup:OU=UNIXTEST,OU=Departments,DC=austin,DC=utexas,DC=edu?one'
There’s also the krb5.conf but that should mostly be the same as the Linux configuration. The Scott Lowe blogs should have the right configuration to start with (though I can post our Solaris one if needed).
One thing I’ve noticed on the Solaris side with this configuration is that if you’re logged in and authenticated via kerberos, you get a wall notice whenever your kerberos ticket is near expiring. I don’t know if this is configurable or not. This is certainly different than the Linux implementation. I think.
BTW, if you’re at UT, I will be providing some more explicit directions for people to play with at the next sync up meeting on this. If you’re not a part of the meeting already, contact me and I’ll talk with you offline.
Tags : activedirectory, ldap, solaris
Categories : Uncategorized