Slashdot Mirror
pam_ldap/pam_krb5 Authentication Against Active Directory?
Very Jerry asks: "Here's my problem. I'm currently in the middle of unifying all of our logins here at my place of work because of all the usual reasons (users forget passwords all too often, leaving them more resistant to setting up more complex passwords). Now we have an Active Directory domain setup here, and I was hoping to have all the users authenticate to that. SFU 2.0 is out of the question because it still leaves you to define extra attributes on the user in Active Directory Users and Domains. After a bit of searching, I've found out that pam_krb5 and pam_ldap have been used with success for authentication, but wherever I turn, there are no specific details. I'm currently 2 weeks deep in to this with no progress and a looming deadline. If anyone could point me to some good, specific instructions (specific to Active Directory, not just OpenLDAP) or help me out with a couple tips, it would be much appreciated."
NDS is absolutely the way to go. We currently use NDS on all of our servers: NetWare, NT, 2000, and Unix. Single point of management, fully LDAP compliant (unlike Minion of Satan's), fully leveragable. How else could only three guys run a 10 server, 3000+ user network?
Hi,
We have had similar issues regarding Microsoft's Active Directory product at Amaa Fui. We were switching from a Unix based kerberos system to one that used Microsoft's.
Here are some solutions to the same problems you had. Firstly, you need to patch your w2k boxes to the latest pack. Then install the beta k5 updates from Microsoft beta w2k site. These updates remove the slight changes Microsoft made to kerberos, and thus makes it compatible with your other systems.
Once those are patched in, you need to install Heesi optimizer (This can be found on any download site), I recommend this, cause this would go through your AD configuration and kerberos setup and tell you exectly where your security is weak and so on.
Once everthing is in place, you can move to more secure passwords and corportation wide access to single passwords. But let me warn you, you still need different passwords on resources that are of a criticial nature.
Also ensure everthing is behind firewalls and if your using VPN install the latest patches from Microsoft site, We run OpenBSD and Ipsec, they work very well with the current configuration.
Our systems include, Windows 2k/nt, Linux i386/alpha/ppc, Mac OS 9/X, HP/UX, IBM AIX, Solaris and an old VAX system. All of them are maintained by the w2k based kereberos authentication systme and LDAP for directory stuff.
Everthing works well and I'm very satisfied, only concern we have is that Microsoft's version of kerberos is very slow to authenticate our user. This creates some problems, specially since some of our internal services have authentication decay in it, to solve this problem we just moved to better hardware, but this is something Microsoft has to solve on their own.
Good luck with your setup and hope this helps, if not you can send me an e-mail to, fadaboi@NOSPAM.riyaasath.com
Fadaboi Kesbe
Done at least half of that...
Authenticating users against AD with pam_krb5 works fine. Just list the DNS names of your Win2k domain controllers in the config file just as if they were normal Kerberos servers, and use the AD domain as the Kerberos realm.
When I did this, I still had local passwd and group files. But it should be possible to move that stuff into AD. You would have to modify the AD schema to include that info in the directory (that's not a task for the faint of heart). Once you do that, though, it's pretty easy to query AD from Linux.
Where I work, we master all of our accounts for UNIX and NT, along with all of our email routing, our NFS volume definitions, our automounter configuration, and our DNS, in Ganymede.
We synchronize passwords from Ganymede into NIS, Samba, and our Windows NT PDC. We also configure tacacs and radius, and LDAP from the same master database. Ganymede provides a high quality GUI interface, and allows you to designate privileges over the directory database to as many classes of administrators as you like. Several people can be simultaneously browsing and making changes to the database, and when transactions are committed, a background thread updates all of the network services. Ganymede is the closest thing that the open source community has to NDS or Active Directory, in terms of being a complete management solution, even though it is not based on LDAP and it does not scale anywhere near as well as an Active Directory or NDS. If you are looking to manage a single location, however, Ganymede will do the job right.
Take a look at the web site in my .signature, below. Ganymede 1.0 is due out within the next week, along with a userKit that supports password synchronization for UNIX, Samba, and Windows NT, with password quality checking handled by Clyde
Hoover's excellent nPasswd
passwd validation suite.
- jon
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Anyone seen a good resource/howto for authenticating 2k boxes against OpenLDAP? Seems that iPlanet has this going somehow with their product. There's no way in hell we're iplementing AD at my site. As it stands, I've yet to find any decent documentation for how to setup a schema that MS will be happy with, and more importantly how to tell 2k to consult same. FWIW, Apple's done a great job of this with OS X-admin users have to be in the NetInfo db, but mere mortals can be looked up from any LDAP server with noting more than a check box in System Prefs. Nice. Somehow, I have a feeling this is one thing Redmond *isn't* going to steal...
Regards,
ehintz
Okay. Enough of this shit. FUD killing time.
/etc/passwd) in two formats: the encrypted NTLM passwords, and the LAN Manager hashes. Since the LAN Manager hashes = NT passwords, that's how L0phtcrack gets your pwd's. But, NT has to be SHUT DOWN (when installed on an NTFS part) to get the SAM file to feed it into L0phtcrack. That's where physical security comes in. And, since NT can't protect the passwords when it's shut down, since SP3 there's a utility called SYSKEY which encrypts the SAM when NT is shut down. L0phtCrack can't touch the hashes then. BTW, SYSKEY is not on by default on NT. It is on Win2k boxes with SAM's (Pro and non-DC member servers). Go figure.
Let's get this straight. MS Does NOT pass clear text passwords over the network. There are basically three types of authentication on MS networks:
1. LAN Manager hashes: This is where the password is simply 'hashed' (weak obfuscation) and not encrypted. Used by LAN Manager, Win 3.x, DOS, and 9x clients authenticating to NT and Win2k DC's. Also used by NT in a non-trust same username/password on both sides situation. Easily snooped, and when fed into L0phtcrack, can be broken. ie: if two users' passwords were "luser", they'd have the same hash representing them.
2. NTLM (NT LAN Manager): Used by WinNT against all DC's and Win2k boxes authenticating against NT DC's. Totally encrypted. The client does a secure, encrypted RPC "trust" with the domain controller, and then passes the name/password combo to the DC, which then passes back an access token. CANNOT BE SNOOPED OR BROKEN. Two versions: NTLM v1 and NTLM v2.
3. Kerberos: Used by Win2k clients against Win2k DC's. Even more secure ticket-passing scheme. 'Nuff said.
Now. You see what I said that NT passwords can't be snooped or broken? I'm serious. It's impossible. LAN Manager hashes, however...Easy. So, you asked how in the hell does L0phtcrack break NT passwords?
Here's the funny part: it doesn't.
On every NT box, the passwords are stored in the SAM (equivalent of
On Win2k DC's, everything is stored in the AD database. Try and crack that. I'm sure it'll eventually be done...but it'll take a long while.
So, in short: Don't use downlevel (non NT) clients, turn on SYSKEY, and the LAN Manager hash scourge will all but be eliminated.
However, there is a Directory Services Client for 9x/NT that allows it to use NTLM v2 in a Win2k network. I still wouldn't use 9x.
In other words...don't talk about which you do not know.
Cheers,
-Kevin, MCSE+I/MCT
My posts don't reflect the opinion of my employer, and my employer's opinion doesn't influence the content of my posts.
We did that where I work, under Solaris, last summer. What we did is use a perl script I wrote to create a passwd file out of Active Directory (with all the passwords set to NP), then did the authentication using pam_krb5. Set Kerberos up like normal, it it pretty much all falls into place. The only hard parts are programs that don't play nice with pam. I think I can find the Perl script if you'd like it. Email me at lopresto@writeme.com. Good luck!
Visit me on #weirdness on the Galaxynet.
I dont want it being posted on the front page of slashdot and having my bandwidth sucked up by casual browsers.
So, you'd rather that the DOC file be downloaded? Why? It saves no space; in fact compared to your average HTML document + images, DOC files are usually much larger, which means more of your bandwidth.
Alternately, you may not intend to offer this over the Web. Well, then problem solved. If you send someone a zip (tgz, hqx, etc) file with the HTML + images + binary files, you are no worse off than if you sent them a DOC file, except more people can view it.
If you want to read my document, then get a DOC viewer. Elsewise, bugger off.
Then I (a sysadmin, presumably your target audience) choose the latter. I have no time for exploring proprietary data formats in order to get the information I need. I'll wait until someone produces a HOWTO in the standard format....
--
Aaron Sherman (ajs@ajs.com)
I'm certainly not a Microsoft fan, but I have to stop FUD when I see it. The above is false. The SMB side of my network is 95/98/NT/2000, and there are no clear-text SMB passwords floating around. The Win 95/98 machines authenticate against the NT domain, and do it without plain-text passwords. Same thing when the Linux machines need to connect to an SMB share. So, sorry, but that's just not true.
They do pass around password information that L0phtcrack can work with, though, so if the passwords are weak, they'll be easily broken. It's essentially the equivalent of sending out /etc/shadow entries unencrypted on the network.
Gumbo
Novell's NDS (I refuse to call it e-directory) can interoperate with Win2K and Linux. If you believe their marketing... Anyone tried this? We are thinking about it, but who wants to blaze the trail?
"I like to play with things a while... before annihilation!" Ming the Merciless
Somewhere on MS's site is some code for adding/deleteing/modifying users from Active Directory along with a script that could cull the users from active directory and allow you to import that into a passwd file (minus the passwords, which would be authenticated via kerberos). This is certainly not for the faint-at-heart, and I looked into it for a while and eventually gave up on that idea because it was simply too complex and too likely to break for no apparent reason.
I used up all my sick days, so I'm calling in dead.
Now, having UNIX clients authenticate to that server is really straight-forward. Just install Heimdal and kth-krb and set it up. The passwd file is distributed using a cron job. It works fine, don't worry.
The Windows clients, at least W2k clients, should be able to authenticate to the KDC, and I think you can solve the rest of the centralized account management through AD.
See, all you clients will use KRB5 or at least KRB4 authentication so you should have a potentially secure system. If you need more PAM modules then you can use the ones from MIT kerberos as well, or Naomaru's.
Were I work we were looking for a way to manage our hosting customers passwords between linux and unix so updating passwords / accounts would be easier.
My solution was Samba-TNG with LDAP, using pam-ldap on linux (with a base DN for each server) and a DN for the NT servers... Samba-TNG becomes the domain controler, and therefore lets users log in against it.....
Just my $0.02
Driven by 100% sarcasm - fueled by the need to be heard.
Comment removed based on user account deletion
Comment removed based on user account deletion
I asked abot this type of cross-OS authentication integration via Kerberos back at a Win2K launch event after reading about their highly touted Kerberos support. After chewing up and spitting out several Microsoft PR drones, I located a guy who appeared more knowlegable.
While, yes, Microsoft has adopted Kerberos for authentication, No, it was not compatible with any existing Kerb tickets. Aparently, Microsoft, in their infinate wisdom, chose to place Win2K domain authentication data in the comments field of Kerb tickets generated via a Win2K login.
This has the result of making it possible to use tickts generated through Win2K authentication within treditional UNIX Kerb realms, but tickets generated outside Win2K would not work. There would be an easy solution to this problem if Microsoft would release details of the chhanges they made to the Kerb ticket format. As of my inquiry (Feb 2000) Microsoft had not provided details of these changes. This may have changes since then.
--CTH
--Got Lists? | Top 95 Star Wars Line
The problem with unifying your logins is of course that once an attacker has compromised ANY of your user's passwords, they now not only have access to your network, but they also have authenticated access to ANY resource which that user has access to. From here, it won't be long before they own your network.
Is this what you really want? Again, it isn't, if you care about security.
Now, because I gotta get my shots in, you also should not be doing your authentication on a Windows machine, because Windows-based authentication is inherently brain-dead.
If an attacker manages to get onto your network, they'll probably be able to sniff someone's password within about 5 minutes since Windows will use plain text unless you're in an all-NT/2000 environment. Once they have that, it will take about 2 minutes to get your password database. At this point, they can log off, crack passwords at their lesiure, and within about 4 hrs they'll have over 90% of your passwords using l0phtcrack (which, by the way, will happily sniff passwords off the network for you too).
You should use a solution that allows encrypted authentication, and that pretty much means Unix or a third-party authentication package for Windows. Throw AD away.
Have a nice day!
I stand corrected... hey, I was reading it from M$ exploder... :)
I tried forever with kerberos and ldap and it was getting me nowhere. The big problem in getting password unification is Windows have it's one-way password hash and unix has a different one-way password hash. The goal is to generate both hash's at the time the user changes his password. There are a number of solutions but here is the easiest I've found. You say you don't want to use SFU 2.0 but I think you're missing out. SFU NIS adds a the unix crypt password hash for the user into the Active Directory. The crypt has gets updated with the Windows hash every time the user changes his password. And with the NIS server running on windows we have and easy way to retrieve the user list and crypt passwords. We tried using SFU NIS services as the master YP server but that was a mess. Here is what I've do: Setup SFU NIS on your domain controllers and use a bogus YP Domain. Then setup a real UNIX YP master with the real YP domain that all the unix machines will use. Set the Unix YP master to also bind to the bogus SFU NIS domain. then write a script that will 'ypcat -d bogus-domain passwd' and look for changes. When the script sees changes it should add them to the real domain's master yp files and do a make in /var/yp. put that script in cron to run every five minutes.
Now the windows domain becomes the master auth info repository but you can unmarry yourself from windows at any time.
When you add a user to the windows domain the script will see the change in the bogus_domain's yp map and it will just add the line to you master yp's passwd file. When a user changes their windows password the unix crypt password shows up in the bogus domain and the script just replaces the old line for that user with the new one in the master yp map.
All user addition and password changes must be done from the windows side but you only have to do it once in one place.
Granted SFU NIS makes you enter in additional information like UID, GID etc... and groups are a bit tricky. But don't you want that? Having Windows make up necessary Unix attributes is a recipie for disaster. This works well and since you are filtering all the entries through your update script you get much more fine grain control of the unix side.
My goals were to have a single place for account creation and modification and make it so that users only have to change there password in one place. This does that. It's not pretty but it works.
If anyone is interested I can email them the scripts I've writted to generate and update a master yp maps from the windows NIS maps.