Jyri Virkki

« Web Server 7 ECC... | Main | CEC 2006 »
http://blogs.sun.com/jyrivirkki/date/20060911 Monday September 11, 2006

Using Web Server 7 with Microsoft Active Directory

Among the many new security-related features in Web Server 7 are a few new configuration elements for the LDAP auth-db (authentication database).

Here is a summary:


search-filter [optional] The search filter to use to find the user. The default is uid.
group-search-filter [optional] The search filter to find group memberships for the user. The default is uniquemember.
group-target-attr [optional] The LDAP attribute name that contains group name entries. The default is CN.

One use case for these configurable search options is to interoperate with Microsoft Active Directory (MSAD). The problem with MSAD is that user ids are not kept (by default) in the usual uid attribute. For this reason, when the LDAP auth-db attempts to search a MSAD directory to find a user, it will never be able to obtain a match since it is attempting to match on the uid attribute.

In 7.0 we can now set the search-filter attribute to override the usual default. In MSAD the user is kept in an attribute called samAccountName. Here is a sample LDAP auth-db configuration for MSAD (showing a minimal configuration, other options can of course be specified as usual): 

<auth-db>
	<name>ldapMSAD</name>
	<url>ldap://crashbox.sfbay/dc=sfbay,dc=sun,dc=com</url>
	<property>
		<name>search-filter</name>
		<value>samAccountName</value>
	</property>
</auth-db>

P.S. Of course, I should probably point out that a better solution is to simply upgrade to Sun's own Directory Server instead!

Posted at 09:59PM Sep 11, 2006 by jyri in WebServer  |  Comments[4]

Comments:

This looks almost too good to be true. In fact it does have that problem: IT DOES NOT WORK.
You can not override the default LDAP search options this way. Not in 7.0 and not in 7.0u1 (at least on Sol10 / x86). I tried what you wrote about and then some other stuff I could dig up or think of. (I must say this was still some of the most helpful info I could google up about the xml options for the auth-db / LDAP / AD topic - so thanks anyway :-) )
Anyway - whatever you do, whichever version - the results are the same: config accepted and deployed, bind suceeds, and then sjsws does an LDAP query _FOR UID_ (check that with a sniffer, no trace of the defined search filters anywhere on the wire). Stupid exceptions in the logs (mostly about the admin UI not being able to display "nothing" and the server not being able to handle the response that comes back to the bad query) - nothing meaningful.
I almost was happy this could work out - and wasted a afternoon on nothing. Shame on Sun, really, for not mentioning this anywhere AND not keeping a proper documentation of the auth-db options, not even mentioning that the names of the options are cryptic and misleading. It is not a disaster that AD auth is not possible - you can do some tricks to make that work, but wasting people's time by not telling them they can't do something (yet?...) and making them think they goofed something up themselves is really not nice.

Posted by Jacint on June 27, 2007 at 02:17 PM PDT #

Authenticating from WS7.0 to MSAD is tested daily on every build, so we know for a fact that it works as advertised. It is certainly possible that your setup is somehow different from the ones that are QA'd. I encourage you to provide the details, so someone can look at it. Note that Sun doesn't do tech support in blog comments ;-) The best location for providing that info is by starting a thread in the web server support forum: http://forum.java.sun.com/forum.jspa?forumID=759

Posted by Jyri on June 28, 2007 at 07:17 PM PDT #

Thank you for the reply, I certainly will try the forums, although someone with the nick "bartmcp" has already had a hard time with this as far as I could see, to no avail.
Actually I posted here beacuse although your blog is not a tech support place in and of itself, it is de facto the only usable, "easily digestable" source of information Google comes up with. In fact in the forums you mentioned, the posts are referring to this page for the solution, so technically you ARE the only more-or-less verified tech support on this topic ;-). That is why, in my post, I also stated that the documentation is inadequate on this topic - I could not find any other site/forum/doc that was either not a loop back to here, or managed put these configuration options, or their way of being parsed, or debugging them into context.
Thank you again for planting the hope, I really appreciate your getting back to me on this.

Posted by Jacint on June 29, 2007 at 01:34 AM PDT #

Thanks for the feedback. I have let the documentation team know that it'll be useful to add this kind of example.

Note that doc updates are a long cycle, so until then, continue to refer to this blog article.

Posted by Jyri on July 10, 2007 at 03:04 PM PDT #

Post a Comment:
Comments are closed for this entry.