Skip to main content
Welcome guest. | Register | Login | Post

Managing Linux Through Windows Active Directory

27 replies [Last post]
supermike's picture
Offline
Joined: 2006-02-17

Introduction

Of interest to me are times when people want to claim that Linux can't fit in somewhere. I'm not an advocate for Windows, but I want to prove that Linux cannot be bullied into a corner where it cannot fit into some other kind of architecture. Regarding a Linux system that might need to authenticate Windows users upon it, either for SSH, local login, or web app logins, this is such a case.

Did you know that Linux can authenticate with Windows AD and doesn't need a big honking third-party product? However, in a recent article by Steven J. Vaughan-Nichols...

Managing Linux Users the Active Directory Way
http://www.eweek.com/article2/0,1759,1949614,00.asp?kc=EWRSS03129TX1K0000616

...he mentioned that there's a product called "Centrify DirectControl Suite 3" that helps your Linux users authenticate to Windows AD and also has an API by which all of your Linux web apps (J2EE, PHP, RoR, AJAX, Perl/Mason, etc.) can authenticate to Windows AD. This can provide a single-signon, meaning that not only can you have Windows login accounts work on a Linux system, but have Windows login accounts work inside the web apps hosted on that Linux system. You can perhaps even integrate the database (such as PostgreSQL) with integration of the Linux system and therefore have integration to Windows. The concept of getting everything to talk on a single-signon is often called a buzzword, federation. Star Trek fans should enjoy that.

When I first read this, it was obvious to me that I would have a few retorts to this. First, why not ask the questions, "Why not have Windows authenticate to Linux?" or "Why not have a central LDAP Server and have all systems authenticate to that?" or "Why do we have to have these stupid, expensive, insecure, broke-down-all-the-time, malware-infested Windows servers and workstations in our office, anyway?" However, that's a hillariously fun discussion for another day. Second, I knew and had tested the fact that it takes little time to authenticate Linux to Windows without having to pay for a product.

The Centrify product seems to go through a tremendous amount of busy-work that is simply not necessary. Within a couple hours, you can build this connection for yourself, allowing yourself to have Linux accounts as well as Windows accounts login to your Linux systems. You an also use some cheap means to authenticate your web apps to Windows as well. It is not that hard, although I do not recommend this for anyone that is not an intermediate to near-advanced Linux user.

The way this is achieved is by altering a system called PAM, which is the authentication module on Linux, so that it uses Windows AD Kerberos integration.

The main thing I recommend first is that you test on a non-critical system and that you make backup copies of each file you edit. Note that messing with the Linux authentication, if a mistake was made, could cause you to be locked out. If you blow the authentication on it, then you'll want to either reinstall it or use the technique on your distro where you reboot into kernel safe mode or something, remount your disk, roll back your file changes, and reboot back into normal mode. On Ubuntu, this rescue mode is well-documented on the web and I have used it once in an emergency with success. Other distros have different ways to do this and it's called a "rescue mode" or "recover root" task if you Google for it. I also recommend you test this a couple times so that you know how to do it in the event of an emergency.

Installation

Connecting Linux Authentication to Windows Authentication

Here, we will connect Linux authentication, whether it be from SSH command line or GDM, XDM, or KDM GUI authentication, to Windows authentication. You can use either Linux accounts or Windows accounts on such systems.

Note my instructions below work with Ubuntu Linux, specifically the Breezy release, which uses the 'apt' tool to retrieve new updates. Your distro instructions may be slightly or significantly different.

Note also where I have "MY_AD_DOMAIN.COM" below, please replace it with the name of your domain, such as "jacksdiscountwarehouse.com", etc.

1. Ensure you are only using a test Linux system and know the process to reboot into safe/rescue mode as root, should your authentication fail. As you make changes to any file, save a copy of it first!

2. Turn off your firewall for now while testing. You can do that with:

iptables -F

3. Turn on (uncomment) Universe option in /etc/apt/sources.list. (When all done, turn it off again and do apt-get update.)

4. Do this:

apt-get update
apt-get install krb5-user

When you install this, note that a window will pop open and ask you for the IP address (twice, I think) of your closest domain controller for the domain with which you wish to authenticate.

5. Edit your /etc/krb5.conf file like so, replacing "MY_AD_DOMAIN.COM" with the name of your domain and note other instructions preceded by a comment, below:

[logging]
default = FILE10000:/var/log/krb5lib.log

[libdefaults]
ticket_lifetime = 24000
default_realm = MY_AD_DOMAIN.COM
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc

[realms]
MY_AD_DOMAIN.COM = {
# use IP address of closest DC for domain to you
kdc = 192.168.0.2
}

[domain_realm]
#this is case sensitive
#change the lowercase versions as well
.my_ad_domain.com = MY_AD_DOMAIN.COM
my_ad_domain.com = MY_AD_DOMAIN.COM

6. Edit /etc/nsswitch.conf like so:

passwd: compat winbind
group: compat winbind
shadow: compat
hosts: files dns wins
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

7. Edit /etc/pam.d/common-account like so:

account sufficient pam_winbind.so
account required pam_unix.so

8. Edit /etc/pam.d/common-auth like so:

auth sufficient pam_winbind.so
auth required pam_unix.so nullok_secure use_first_pass

9. Edit /etc/pam.d/common-password and change the max parameter to 50:

password required pam_unix.so nullok obscure min=4 max=50 md5

10. Edit /etc/pam.d/common-session like so:

session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel

11. Do this:

mkdir /home/MY_AD_DOMAIN.COM

...note that I don't know if this is a requirement or not.

12. Edit /etc/hosts so that you have your FQDN on the 127.0.0.1 line before localhost, as in "127.0.0.1 UBUNTU.MY_AD_DOMAIN.COM localhost". This would mean that my hostname "UBUNTU" is given this same name in the AD.

13. Ensure that the AD account you want to use for authenticating also has the power to add a server or workstation to the AD.

14. Ensure that the AD account has an account on the Linux system by using the 'useradd' command. Note that the password should not be the same as the AD account. This will cause the PAM to detect that and immediately pass the request on to the Windows AD as a second step. And that is where the user's password will work.

15. Fire up Kerberos by doing this:

kinit <your domain account here>@MY_AD_DOMAIN.COM

...be patient here -- takes about 30 seconds to come back.

16. Check to see if Kerberos is giving you a ticket by doing:

klist

...and it should spit back something like:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal:

Valid starting Expires Service principal
03/01/06 22:42:31 03/02/06 08:42:31 krbtgt/MY_AD_DOMAIN.COM@MY_AD_DOMAIN.COM

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

17. Join the Linux system to the domain by first adding the server into the OU in Microsoft's Active Directory through the AD Manager tool on Windows and then doing this on the Linux system in question:

net ads join -U <your domain account here>@MY_AD_DOMAIN.COM

...but note that this account must not only exist in your Windows AD, but also have the power to add servers and workstations into the AD.

For instance, I did:

net ads join -U

...since supermike was a valid login to my Windows AD. You'll also want to use the password you use on your AD.

18. Restart SSH.

/etc/init.d/ssh restart

19. Then, I could do "ssh -l supermike 127.0.0.1" locally and it prompted me for my Windows AD password. When I used it, it passed it on to the Windows AD and utilized that instead. There was no need to worry about storing the password locally on the Linux system or worrying about password synchronization issues.

20. Comment back out Universe option in /etc/apt/sources.list.

21. To add more users, they first need local Linux logins, which you can arrange with the 'useradd' statement. However, please ensure that the passwords are not the same as the AD domain. You can generate some kind of funky password like '5fE#2323G' and use that over and over again for each of these accounts. You see, when the PAM fails to use the Windows password against the local Linux accounts, it will then pass this on through Kerberos to the Windows AD. This will authenticate the user properly.

22. Turn your firewall back on if you know what ports to poke through. I have no clue what ports are necessary yet. I probably will have to use tcpdump and netstat to figure that out.

This completes this task and now you have a way for Windows accounts to work on your Linux system. You can repeat this process on various other Linux systems, federating them with a single-signon.

Connecting Linux-Hosted Web Apps To Windows Authentication

I'm not going to go into a tremendous amount of detail here because it could get rather lengthy to describe this technique in the various web development languages, but if you've done web development awhile on Linux, and are familiar either with a web or socket API in your favorite web development language, or are familiar with shelling out in a background process shell to run the wget or curl command and parse the result, then you are capable of handling this task with minimal instruction.

There's a couple approaches here to get this going fairly easily.

Approach # 1. Turn on Basic authentication with your Linux web app, and turn off anonymous authentication. Or, turn on anonymous authentication, turn on SSL to collect the Windows AD username and password in a secure form. From either of those two techniques, you end up receiving the user's Windows AD username and password. Make your web app shell out into a login shell, and, if you have properly added this user locally on your Linux system, you can test whether that login shell received a command line successfully or generated an error. You can parse for this and pass that back to the web application, letting you know the user authenticated or not. You can write this as an encrypted cookie "authenticated" that can say "This user has authenticated" (or something similar). Then, each page can check for that and deny users who have not done this properly.

Approach # 2. Do the same thing as approach # 1, but instead of shelling out and checking a login shell to see if it worked, connect with a seperate Windows IIS web server to test the authentication. If you bring up a seperate Windows IIS web server that has a page set for Basic Authentication and Windows AD Authentication, and has Anonymous Authentication unchecked, you have the ability to have that Windows AD Authentication set for a particular AD OU. Then, simply put into the page the word "OK". Now, using either a socket API, web API, or shell out from your web page and use either curl or wget commands, you need to use Basic Authentication to connect to this page and test the login. If you get anything besides "OK" coming back, then more than likely either your configuration is wrong or the authentication did not succeed. Letting us assume that the configuration is correct, then you just parse for "OK", receive it, and set an encrypted cookie that says "This user has authenticated properly." Then, from each subsequent page after that, you check for the presence of this encrypted cookie and deny anyone else. (In fact, if you're clever enough, then perhaps you know how to run a Windows IIS web server under WINE on an alternative port on the same system, or under Xen in a virtual machine. However, that's a discussion for another day.)

Conclusion

Using these two processes -- authentication for the SSH or X-based login, plus authentication for a Linux web application -- you can now bring your Linux system into a federated system under Microsoft's platform. However, you may prefer a more secure platform like Linux, and bring up an LDAP server, and have MS Windows servers authenticate to that right along side your Linux servers. An even more delightful conversation about this would be, "Why even use Windows servers on our backend, anyway?" However, one cannot change the world in a day. We can only try. For now, you can authenticate Linux to Windows and show off its power to fit in, anywhere.

AndrewB's picture
Offline
Joined: 2005-12-18

Digg it Here

Hey very good article! Not personally for me, but nice to see it can be done, and it is interesting stuff!

Anonymous
why?

why would you want to??? the point is to remove windows..

Anonymous
Multiple Domains

How do I handle multiple domains? I want to authenticate users who are in several Windows domains using a solution like this. Ideas appreciated.

supermike's picture
Offline
Joined: 2006-02-17

slackwaresupport/guest: Agreed. Why would I want to? I mention that's a talking point in the article. However, in some office environments, with heavy bureacracy above us, what are we to do? Ruffle too many feathers and get ourselves fired? The point of my article is to say that Linux can fit in anywhere. And for some people wanting to bring Linux in but are afraid it won't play along, this might be a door opener for them. At least that gets the little penguin in the tent. From there on out, he can start showing his stuff.

Anonymous
Great

This is great , thank you

Anonymous
PAM for web apps

Since you are using PAM+winbind, why not use
http://pam.sourceforge.net/mod_auth_pam/configure.html ?

This should tie in web apps Authenticating to AD.

Ashay

Anonymous

Nice article!

I'm a little confused at steps 10 and 11, though. What's the reason for the mkhomedir module and the created home directory? No new users are being created at first login, so the mkhomedir seems extraneous. Also, does anything ever get stored under that home directory in step 11 or does it always stay empty?

Here's an article I wrote a few months back on centrally managing users with AD. I'm sure it could be used in conjunction wtih the Kerberos topics in this article. It doesn't cover file sharing with Samba with AD resolved ACLs, though -- that would be the final step in the AD / Linux integration.

http://adminspotting.net/articles/windows/Linux-and-Active-Directory.html

Anonymous
Re: Multiple Domains
"Richard" wrote:

How do I handle multiple domains? I want to authenticate users who are in several Windows domains using a solution like this. Ideas appreciated.

I believe one way to handle that situation is to have domain trusts on the Windows side. So, for example, you have:

Domain1
Domain2
Domain3

Then you set up one-way trusts in Windows AD:

Domain1 TRUSTS ---> Domain2
Domain1 TRUSTS ---> Domain3

Then you have the Linux server join Domain1 with the instructions listed earlier in the article.

I recently joined Redhat ES 4.0 to a Win2k3 domain using a very similar method, and it mostly works (all the critical stuff is just fine, automatic home directory creation is not working). The only problem is that the directions for joining a domain are Linux distribution-specific, and you may need two or three references printed out and sitting in front of you to get the procedure down properly. Some distributions now have built-in wizards (like RedHat ES 4.0) to do this work for you, but many articles on the web discourage you from using the wizards, saying they are buggy (for example, if you need the Kerberos V package installed, the wizard may not do this for you).

Any security concious folks thinking about doing this should know there are some serious limitations in the security features of Winbind, such as not being able to create a no-shell login for one domain user without affecting all domain users.

Anonymous
Automatic home directories
Joe wrote:
Nice article!

I'm a little confused at steps 10 and 11, though. What's the reason for the mkhomedir module and the created home directory? No new users are being created at first login, so the mkhomedir seems extraneous. Also, does anything ever get stored under that home directory in step 11 or does it always stay empty?

The point of the mkhomedir module is so that domain users automatically will have a home directory when they log in for the first time. The alternative is to create their home directory by hand either before or after they log in - if the step is done afterwards, they might need to re-login to use their home direcotry. Either way, it's something that needs to happen only once per user.

Step 11 sets up the directory that holds the domain user's home directories. For example, if you're domain is called Domain1, then step 11 says "mkdir /home/Domain1". Now when domain user "Joe" logs in, his home directory will be "/home/Domain1/Joe".

Anonymous
Re: Automatic home directories
"DonCornelius" wrote:

The point of the mkhomedir module is so that domain users automatically will have a home directory when they log in for the first time. The alternative is to create their home directory by hand either before or after they log in - if the step is done afterwards, they might need to re-login to use their home direcotry. Either way, it's something that needs to happen only once per user.

Right, but Mike talks about creating all the users on the Linux box by hand. This is where I was confused about actually needing the mkhomedir module at all.

"DonCornelius" wrote:

Step 11 sets up the directory that holds the domain user's home directories. For example, if you're domain is called Domain1, then step 11 says "mkdir /home/Domain1". Now when domain user "Joe" logs in, his home directory will be "/home/Domain1/Joe".

OK, that clears that part up. Thanks!

Anonymous

In regards to Centrify, it's a great product that works well even when your Windows admins have thoroughly screwed up their domains. I spent days working on a solution like this, only to be rebuffed with bad ticket errors. In a corporation, their solution is reasonably cheap on a cross-platform setup with Unices, Linux, and Macs.

Anonymous
Re: Automatic home directories
&quot;Joe&quot; wrote:

Right, but Mike talks about creating all the users on the Linux box by hand. This is where I was confused about actually needing the mkhomedir module at all.

There's a an entry in the Digg listing that points to this article (http://digg.com/linux_unix/Managing_Linux_Through_Windows_Active_Directory#c1498804) about the 'getent' command. 'getent' will populate the user list from the domain for you automatically. I forgot I had done this when I joined my Redhat box to the Win2k3 domain. I don't believe this automatically updated though.[/url]

Anonymous
useradd

Great article. It's nice to have a clear step-by-step.

The one problem I have is that I don't want to have to add the user manually to the linux box before they log in. I want that done for me when they log in the first time.

We have 25,000+ users in our AD domain. We have labs that are used by an ever-changing subset of these users. I need an option that runs "useradd" for the new user if they don't exist, automagically. There should be a shim or hook that can be added to PAM to check for the existence of the linux account and create one if it is missing - or obtain UID and GID from another source and not have to create a local account at all (!)

I've gotten this sort of thing to work before with Xandros and SuSE, but they have a GUI setup and it's all "black-box" stuff - I wasn't able to figure out how they were accomplishing it.

Anyone have any Ideas?

Anonymous
Re: useradd
"NtroP" wrote:

Great article. It's nice to have a clear step-by-step.

The one problem I have is that I don't want to have to add the user manually to the linux box before they log in. I want that done for me when they log in the first time.

I went back to my production Redhat server to test some things. It seems that users can automagically log in (looks like 'getent' is just for testing?). The key appears to be setting up the 'idmap' entries in smb.conf as well as a proper PAM configuration for user logins. This is addressed in detail in the Samba HOW-TO guide.

Check out these links:

http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html
http://www.enterprisenetworkingplanet.com/netos/article.php/3487081
http://www.experts-exchange.com/Networking/Linux_Networking/Q_20765134.html

supermike's picture
Offline
Joined: 2006-02-17

NtroP: Yeah, I do have an idea. Unfortunately I haven't heard of a PAM mod yet that can tackle this.

My idea is to export your Windows AD list of users to a text file and import into Linux. This is available on the menus in Windows AD Manager, I recall. Once there, create a Bash script that does the useradds. Any password will do on Linux, so you could make it tough. What will happen is that the PAM, upon user login, will fail these accounts on Linux, then forward these onto Windows AD.

Another route, as a follow-up, is have a cron entry in /etc/crontab that looks for failed logins in the /var/log/messages file. It can do this every minute during prime hours when the server might be most active, and perhaps every 15 minutes during non-prime hours. Once it finds this entry, it can then do a command-line test to see if this user exists in the Windows domain. There's probably a GNU command-line utility for checking that. If not, you could build one by interfacing with a remote IIS server. You pass it the user ID and, under local admin rights, it could check with the domain using the 'net user' command to see if returns a result. If it returns a sufficient result, you could then use useradd to create this login. To communicate with that server, you could use wget or curl from Bash, or use curl API from Perl or PHP. If you need help in building that, you might be able to put out a bounty here:

http://www.getafreelancer.com/

supermike's picture
Offline
Joined: 2006-02-17

DonCornelius. You really appear to know your stuff! Smiling I welcome you to this forum.

Anonymous
Re: useradd
"NtroP" wrote:

Great article. It's nice to have a clear step-by-step.

The one problem I have is that I don't want to have to add the user manually to the linux box before they log in. I want that done for me when they log in the first time.

We have 25,000+ users in our AD domain. We have labs that are used by an ever-changing subset of these users. I need an option that runs "useradd" for the new user if they don't exist, automagically. There should be a shim or hook that can be added to PAM to check for the existence of the linux account and create one if it is missing - or obtain UID and GID from another source and not have to create a local account at all (!)

I've gotten this sort of thing to work before with Xandros and SuSE, but they have a GUI setup and it's all "black-box" stuff - I wasn't able to figure out how they were accomplishing it.

Anyone have any Ideas?

I totally apologize for plugging my own article a second time, but that's what I've accomplished:

http://adminspotting.net/articles/windows/Linux-and-Active-Directory.html

By following those steps, users that are only located in Active Directory will be able to connect to any Linux computer. The UID, shell, home directory, etc is all stored in AD via the Unix attributes found in either Server 2003 R2 or R1 with Services for Unix.

However, I can't remember if existing users will automatically get their attributes filled in after you install the Unix Attribute support or if you'll have to do it manually (or via a script).

Also note that if your userbase is constantly changing, you might want to put some scripting in place to check for removed or disabled users and clean their home directories up on the Linux computers as that type of synchronization isn't available..

Anonymous
Re: useradd
"DonCornelius" wrote:

I went back to my production Redhat server to test some things. It seems that users can automagically log in (looks like 'getent' is just for testing?). The key appears to be setting up the 'idmap' entries in smb.conf as well as a proper PAM configuration for user logins. This is addressed in detail in the Samba HOW-TO guide.

getent is used for resolution with the /etc/nsswitch.conf file.

For example, I'll describe the passwd entry. By default, "compat" will just be there. so if you do

getent passwd

I'll just cat your /etc/passwd file

If you replace compat with files, it'll do the same thing.

If you replace compat with ldap and you have ldap correctly configured to connect to Active Directory (or any other LDAP server for that matter), it'll list all the users found in the LDAP server.

Anonymous
Re: useradd

Ugh.. those last two posts were from me. I guess making a user account would have solved that problem. Sticking out tongue

libervisco's picture
Offline
Joined: 2006-05-04
Re: useradd
"Joe" wrote:

Ugh.. those last two posts were from me. I guess making a user account would have solved that problem. Sticking out tongue

Hehe indeed, and you are welcome to join! :smt023

Offline
Joined: 2006-04-19
Re: Managing Linux Through Windows Active Directory
"supermike" wrote:

Introduction

Of interest to me are times when people want to claim that Linux can't fit in somewhere. I'm not an advocate for Windows, but I want to prove that Linux cannot be bullied into a corner where it cannot fit into some other kind of architecture. Regarding a Linux system that might need to authenticate Windows users upon it, either for SSH, local login, or web app logins, this is such a case.

-----

This whole process is too much trouble and it's bound to break and leave you pulling your hair out.

Like 'em or hate 'em, Microsoft provides software to do just what you describe. It's called Services for Unix (SFU) and it's a free download. It includes NIS and NFS servers for Windows, and then you just set up NIS authentication and an NFS client on your Linux machines. Then, just like you were using a Solaris NIS/NFS server (for example), you authenticate against Active Directory and also have access to your home directory.

If all you want is what you describe later in this post, authenticating your web apps against A.D., simply look into Apache's mod_auth_ldap. I've been using this in production for quite a while now to allow certain Windows users (based upon group membership) access to certain web applications. I even wrote about it on my own site, you can read about that here: Apache Authentication Against Active Directory.

supermike's picture
Offline
Joined: 2006-02-17

jlgaddis: Welcome aboard! I liked your article link that you posted. I may draw on that sometime. BTW, I used to have some relatives in Bloomington. That's pretty country out there.

supermike's picture
Offline
Joined: 2006-02-17

BTW, some have argued that Winbind is necessary, but I found that my PAM authentication technique through Windows AD worked without Winbind running, so I didn't include it. If your testing shows you otherwise, please let me know.

Anonymous
UGH... please don't do all this just for web apps

Web app authentication is much better handled with a simple LDAP bind. If you're in PHP, for instance:

// Given $username and $passwd, try domain auth...
// DC = domain controller, yourdomain.local = domain name
$ad = ldap_connect("DC");
ldap_set_option($ad, LDAP_OPT_PROTOCOL_VERSION, 3);

$bd = @ldap_bind($ad, "$username@yourdomain.local", $passwd);
if (!$bd) {
  // bad username or password
} else {
  // logged in
}
supermike's picture
Offline
Joined: 2006-02-17

jweather: awesome piece of code there! I just might use it.

Anonymous
"supermike" wrote:

BTW, some have argued that Winbind is necessary, but I found that my PAM authentication technique through Windows AD worked without Winbind running, so I didn't include it. If your testing shows you otherwise, please let me know.

You're correct: winbind is not necessary. winbind is simply another choice of reading user information from AD.

winbind will take the UID of the local Linux user and the SID from the Windows user and make a mapping of the two. This is useful in cases where you have Samba file shares on a Linux server and want to make sure the owner is correctly matched between the two places.

The downside to winbind is when you introduce multiple Linux servers into the picture. Each server that uses winbind will have a different UID/SID mapping. So if Windows user Joe is mapped a UID of 1500 on Linux1, it's possible Joe will have UID of 1505 on Linux2. Now if you copy a file (via ssh, rsync or something similar) from Linux1 to Linux2 and keep the UID ownership as 1500, it's no longer owned by Joe according to winbind.

To get around this, you can set up an LDAP server that maps the two mappings between each other. I've never done this but that's how things were run where I work before I got here. Since then, we've moved to a straight LDAP connection with centralized UIDs. This solves the mapping maps problem but we still need winbind for the security ACLs.

So, long story short, you're correct when you say it's possible to not use winbind!

Anonymous
Step 14, defeats the purpose of having a single directory ...

re: Step 14

"14. Ensure that the AD account has an account on the Linux system by using the 'useradd' command. Note that the password should not be the same as the AD account. This will cause the PAM to detect that and immediately pass the request on to the Windows AD as a second step. And that is where the user's password will work."

Now you have islands of identity, you have a situation where JoeUser has a local Linux account with password foobar, and JoeUser has AD password of ADfoobar. Now imagine having 100s of Linux systems, where you have 100s of JoeUser with password foobar. So if you fire JoeUser, you actually have to remember to disable JoeUser not only on AD, but to safe also the 100s of systems (assuming you remember where you set JoeUser up). Ouch.

From what I gather the beauty of a Centrify is that the UNIX identity is actually stored in AD, so there is no need for a local login account for JoeUser. Plus you can enforce a consistent password policy across all your systems, because the password policy is based on AD (ie a user's username and password is their AD username and password for all platforms). And AD actually has a much more robust capability as it relates to password policies then most Unixes (e.g. has the concept of password aging, enforces specific times when the user can login, max password length, etc.).

The Centrify product also provides Group Policy capability integrated into it, which is another big win from what i can gather, especially if you have Mac desktops.

Your solution also falls apart if the network link to AD is down, I am under the impression that Centrify has a local cache (ala Windows XP) that allows a user to still log on if AD or the link is down to the domain controller. Likewise i believe it is site aware, so if a particular domain controller is down it will jump over to the next closest domain controller.

Look, not bashing your solution, but the goal of many shops should be single directory, single identity location, etc. be it AD or another directory. I just looked at the 5 minute demo of Centrify on its website, and the value of Centrify is that it takes 2 steps to work -- a rpm and a ADjoin command in less then 4 minutes, vs. your 20 steps in a few hours. Then multiple that by 100 systems. Then factor in Centrify supports 60+ flavors of Linux, UNIX and Mac. Your steps won't work on older versions of AIX that don't even support PAM.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.