Single-Sign-On on Linux using LDAP with Active Directory
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.
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.
http://www.microsoft.com/windowsserver2003/r2/unixinterop/default.mspx
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.)
LDAP IS NOT AN AUTHENTICATION PROTOCOL!
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.
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.
http://www.linuxjournal.com/article/8374
Better article with better scaling. Comes in 4 parts.
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.
http://www.microsoft.com/windowsserver2003/r2/unixinterop/default.mspx
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.)
LDAP IS NOT AN AUTHENTICATION PROTOCOL!
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.
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.
http://www.linuxjournal.com/article/8374
Better article with better scaling. Comes in 4 parts.
<< Home