in DevOps

So, some Solaris updates

Some 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.

Travis Campbell
Staff Systems Engineer at ghostar
Travis Campbell is a seasoned Linux Systems Engineer with nearly two decades of experience, ranging from dozens to tens of thousands of systems in the semiconductor industry, higher education, and high volume sites on the web. His current focus is on High Performance Computing, Big Data environments, and large scale web architectures.
  1. You listed three options. Here’s a fourth, thinking outside the box:

    OpenLDAP works on Linux quite well. /etc/ldap.conf, /etc/nsswitch.conf changes and BAM you’re authenticating with ldap.

    Is there no way to rip out the Sun LDAP client bits and substitute with OpenLDAP?

  2. If we controlled every system that wanted to use this, yeah. Unfortunately, there’s lots of IT shops around campus that want this authentication and we’re trying to keep this as simple as possible for everyone. I think supporting this would be difficult because of things like different support and patching policies in each group.

    One thing we did think about was seeing if we could proxy the LDAP request back to AD and just kill the specific VLV/SSS controls in transit. Sort of the ADAM way of doing it, but (hopefully) not requiring us to keep the entire AD domain synced up.

  3. You can also use OpenLDAP as a proxy to AD, and let OpenLDAP process the SSS/VLV request. The OpenLDAP sorter allows a configurable number of sort keys…

  4. @hyc: Yeah, that was going to be our backup if we couldn’t get the ADAM to work.

  5. I ran into the same issue with Solaris/AD and VLV today. Did you ever resolve this? If so, what route did you go?

  6. Officially, no, we haven’t resolved it. In theory we have, we just haven’t tested it. The solution we’re going with right now is to create an ADAM instance populated with the things we need from AD. We’re configuring the ADAM so it doesn’t allow VLV.

    So, in theory, it works. I was waiting for some changes to be made in our ADAM infrastructure before going forward with our testing (which, coincidentally, have finalized this week so I should be able to test again soon).

    Alex are actively working on this (he’s handling the AD/ADAM side). I’ll poke him to see if he’s got any instructions for setting up ADAM in the way we’re talking about.

  7. So, I’d like to do this. Any chance we can meet up as a group again to discuss it?

    Thanks,
    Charles

    • I’ll let Alex and Dave know so we can figure something out.

Comments are closed.

Webmentions

  • kb.hurricane-ridge.com / Bookmarks for October 5, 2009 2010/01/21

    […] » So, some Solaris updates Just Another ITS Systems Guy – "Problems [seen] with VLV support between Solaris and Active Directory." Post a comment — Trackback URI RSS 2.0 feed for these comments This entry (permalink) was posted on Wednesday, October 7, 2009, at 9:26 am by admin. Filed in Links and tagged active directory, vlv. […]