Joe - I certainly agree that LDAP is not a great mechanism for authentication, for the same reasons. It is, however, available, and meets an immediate need (beats having a seperate identity store in each app server). Getting everyone to speak Kerberos is not a small task. Having a single domain allows us to get away with it (using LDAP for authentication) without hitting some of the issues you mentioned.
Re Websphere, they have indeed improved in some respects, but not in others. They still insist on entering a single LDAP host instead of discovering one, but they do look at a user object's memberOf attribute now to find out which groups they belong to, and they do recursively look at the memberOf attributes of those groups until they are empty, so nested groups 'work'. There's actually an option in the security config that lets you select which directory type you're using, and one of the selections is AD. When you select it, appropriate filters are used for finding users, groups, group membership, etc. Since they have some clue about AD, seems to me it shouldn't be that hard to add the ability to discover DCs, or at the very least, to allow me to give it a static list of DCs so it can fail over if one goes away. That goes for lots of other so-called 'directory aware' products.... BEA WebLogic server still searches for all groups that include user X in their membership list, though. This would not be workable at all, except for the fact that our administrative model is very centralized, and we're able to keep all the applicable groups in the same OU so we can scope those searches down to there. We do keep the app servers and the DCs they use in the same data center, so the number of people who can access those network switches is realatively small. Still, I'd be a lot more comfortable with Kerberos. I'm intrigued by some stuff I've read about J2EE components you can buy that handle Kerberos, but have not had a chance to do any investigation. Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of joe Sent: Sunday, May 02, 2004 8:37 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Active Directory and Other LDAP Integration I want to say a couple of things on this point, however first off, we use cn=sAMAccountName. 1. LDAP is not a good authentication mechanism. Especially how most companies seem to do it with their products. I.E. Simple LDAP Binds. This is not in any way shape or form secure. Use kerberos, kerberos is an authentication protocol, LDAP is a directory access protocol. You can secure LDAP by using SSL or IPSec but vendors should just bite the bullet and do it securely in the first place. Why should their customers take the performance hit of SSL and IPSec because vendors don't want to do the right thing because it is "hard". I am currently working on a little joeware tool that will expose how bad this is a little easier. It will sit and pick off LDAP Simple Binds and show the userid and password quickly and easily with no network monitoring experience or knowledge needed. 2. I have had a run-in with WebSphere in my distant past. They may be better now but there were quite a few issues. The IBM guys really had no understanding of AD at all. First, they liked to hard code servers in versus use the ever present dynamic method of finding AD resources. AD is built in such a way that you don't need dependance on individual servers. It is a great system, the vendors should figure out how to use it (including MS... Cough RUS, cough ADC). Second, obviously clear text words streaming across the network. Anyone who has done a network trace and seen these probably didn't stop laughing in less than 5 minutes. If you have major acceptance of some app in your company that uses clear text passwords anyone with access to the network that the authenticating system or the DC doing the authentication can have a vast majority of the passwords of the users in a very quick and easy fashion. Note, even the janitor who cleans the data center or closet that you keep your DC or Websphere server in has access, he just buys a $10 shared hub and hooks it up between the server and the switch. Heck, I am reviewing a security book right now where the guy is talking about people picking signals right out of the air off of ethernet cables... Third, they came to us and told us our AD servers weren't working correctly because the tests they did were going way slower than they did in the lab... The lab had 12 groups and 5 users... Production had that beat thousands of times over. They were doing some very crappy LDAP calls. The group membership search involved searching for all groups where the DN of the user was in the member attribute. Take a domain with lots of groups and that is a bit slow, take a multi-domain forest and it is either not done at all or extremely painful. All of your groups that are used by websphere should be in a single domain. Preferably a domain with GCs, then Websphere can hit the GC port and ask for the user's memberof attribute and get all of the groups in one shot for any userid from any forest. 3. Be careful as Exchange can cause some heartache with CNs. I believe it is the ADC and occurs when you migrate from 5.5 to E2K/3. If you go with the default settings it will help you out and change your CNs for you. Just something to keep in mind. Possibly one of the Exchange lurkers can pop in more info about that if it is needed. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:43 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Active Directory and Other LDAP Integration All, we are in search of the elusive single sign-on... We are designing/testing pieces of what may become a multi-platform authentication strategy. We've begun with the authentication integration with IBM's Websphere. While we've been successful in its integration (having Websphere on a Linux box authenticate to AD); we have a dilemma with how the DN is created...specifically the CN. The CN appears to default to be the same as the 'Display Name'. With this being the case, a user logging into Websphere's Portal would need to login with what would appear to them as yet another ID using their 'First' and 'Last' names. And that's assuming that our naming standards are intact and haven't had to account for identical names. A way around this appears to have the users logon name and 'Name' [CN] fields be identical. We would then add the "Display Name" column to ADUC and other such AD management tools for our sanity of management. Enforcing/ensuring this setting would not be difficult for us as we use Aelita Enterprise Directory Manager, so we would just create a validation/enforcement rule as well as ensure automatic policy validation. My questions are: Has anyone else run into this problem? Is this really a problem or just what I'm simply supposed to do. Are there other problems that might arise from this change in procedure? What kind of success have people had in having other platforms and LDAP'able' applications authenticate to AD? TIA, Eric Jones, Senior SE Intel Server Group (W) 336.424.3084 (M) 336.457.2591 www.vfc.com List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
