Howard Chu wrote:
Compared to what? AD is one of the *fastest* LDAP servers at delivering this kind of authentication data (individual entries from around 200-300k entries, for example), and since Windows 2003 even does a passable/respectable job of delivering large-directory data (larger entries from millions of records) if you configure it for that kind of data retrieval. For cross platform authentication, I would definitely recommend upgrading to Windows 2003 as Windows 2000 had a number of limitations in speed and characteristics like maximum size of a group.Nathan Hruby wrote:On Jan 15, 2008 5:50 AM, Erling Ringen Elvsrud <erlingre@xxxxxxxxx> wrote:Hello list, I work for a fairly large organization and will probably be involved in planning, installing and maintaining a LDAP based directory service this year. The directory will be mainly used to authenticate developers and systems administrators that need to access RH Linux servers (and also maybe HP-UX in the future). Microsoft AD is used elsewhere in the organization to authenticate users of Windows based desktop computers. The best solution would be to use AD to authenticate users of Unix computers as well, but I'm not sure if it is possible to make that solution work.Depending on your AD forest and how willing your AD admins are to working with you, this is a perfectly viable option. Samba offers the winbind daemon which can talk to AD, and in AD 2003-r2 they've fixed a good number of the compatibility issues between windows and non-windows hosts. There are also several companies that offer integration solutions for Unix+AD.Yes, it can be made to work. But among all the things which AD does poorly (which is, most of them), LDAP authentication is one of the worst. I guess with only 200 active users you should be OK. (LDAP searching is pretty lame on AD too.)
I've tested this with loads simulating thousands of active clients. I was trying to make it fail. I expected it to fail. It didn't! It even degraded gracefully - after I reached the maximum number of transactions per second, it leveled off - it didn't crowbar like our Solaris-based NIS+ servers.
I've never found an LDAP server that is good at 'walking' a map (i.e., retrieving all of the entries like 'ypcat' for NIS), but AD is certainly no worse than the others (and better than most). This is why client-side caching is so crucial for anything except tiny maps.
If you're going to use AD, I recommend doing Kerberos+LDAP and make your clients true members of the domain. This provides increased security and best interoperability (the Kerberos tickets work across platforms).
- Richard