oo-services.com — This article discusses how you can integrate Linux into a Windows-based network by making it authenticate against an Active Directory server and having it get passwd and group information from Active Directory as well.
Jun 4, 2006 View in Crawl 4
jeftekJun 4, 2006
Also Note, Check your AD Schema version before trying to update using the LDF files listed. Windows Server 2003 R2 will have the attributes already integrated for Unix Support.<a class="user" href="http://www.microsoft.com/windowsserver2003/r2/unixinterop/default.mspx">http://www.microsoft.com/windowsserver2003/r2/unixinterop/default.mspx</a>We use Quest's (formerly Vintela) VAS product to integrate the *NIX systems into AD. It offers other benefits founds in Windows systems, now on the Unix boxes (Cache'd logon most imporantly, Group Policy support,etc.)
directorblueJun 4, 2006
Okay, here's the problem with this approach - and it's not technical.By authenticating to AD, these Linux machines now need Windows Client Access Licenses (CALs), which are not inexpensive. In other words, for you to legally bind to AD, I believe it is the case that you will have to pay MSFT for Windows CALs. And, if you used Evolution as your email client with Exchange, you would also need additional Exchange CALs. And, if you use SQL Server anywhere in the mix (even through a variety of proxy layers), you will also need SQL Server CALs. And so on.Just something to talk to your MSFT rep about...
mikedawgJun 4, 2006
First of all, you are correct about LDAP not being an authentication protocol. Kerberos is an excellent solution for many people wanting to maintain a single AD management system, except there is one problem that Kerberos can't solve for our solution. If you try and maintain a list of servers that users can and cannot log into.So for example, in our domain, we have 3 machines, 1) AD running for a single realm 2) Linux machine with pam_krb5, which you wish to auth against the AD server, that allows everyone to access it (that has an account on the AD system), and 3) Linux machine with pam_krb5, which you wish to auth against the AD server, that you want a select few(er) people to access that also auth against the AD server.Using Kerberos, computer 2 can auth against the AD server (1), and gain access to the machine, however, there is no way to maintain user access control for server 3 in this example.The only real way to control access is to use an LDAP solution.
roachJun 4, 2006
Firstly, Microsoft will support you even if you make schema changes, thats what the schemas is there for, to use, there are many products that reauire schema changes. But Microsoft support is a thing of wonder anyway, we've had to use it a few times and this last time for a cluster playing up they could only offer a solution where we build a whole new cluster.For my enterprise I purchased Suns AD Sync identity managment product. It is very cheap as the JES directory server stuff is free anyway. It is supported by Sun so if it breaks you still have someone to call.A job copies any new AD members to the Sun directory, and Unix boxen authenticate off that, it caches the encrypted password. No need for AD schema changes.Maybe it's not SSO but at least you are using AD creds on Unix, and it is supported.
trevahahaJun 4, 2006
Eh this is ok, but a better way to do a SSO is via ADFS
zoopJun 5, 2006
First off...this is done much easier with a real directory such as Novell's eDirectory (and there is NO schema changes necessary - it's ready to go).I can't help but ask...why would you want to even use AD to do this? You are taking a secure system and using an insecure system to authenticate against? Hmm...seems quite idiotic. Nevertheless, idiotic is as idiotic does.