Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

pam_ldap/pam_krb5 Authentication Against Active Directory? 90

Posted by Cliff from the interoperability-as-the-goal dept.
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."
This discussion has been archived. No new comments can be posted.

pam_ldap/pam_krb5 Authentication Against Active Directory? More

pam_ldap/pam_krb5 Authentication Against Active Directory?

Comments Filter:

  • Re:Solutions (Score:1)

    by Anonymous Coward
    You mentioned Heesi Optimizer. Well, I would like to warn anyone again using this product. I recently too setup a Kerberos setup as mentioned above by fadaboi, but I had very bad experiences with Heesi. Once I started the optimizer, I noticed our hubs started blinking wild, I cut the offending Heesi, and tried again with the network card in promescuious mode using netdump. It turned out, Heesi was sending a lot of information regarding your network setup (nothing really sensetive, but still) to Heesi Corp. I got really offended by this and discontituned using it and wrote to their support group. It's been 2 months, still no reply, not to mention Heesi is supposed to be based in Sweden?? But they dont have a proper corporate page you can access 100% of the time. I saw them moving twice the past 9 months (their web site). And due to all this, I highly recommend you do all optimiztion tests using other tools and keep your hands away from Heesi.

    Enjoy

  • Re:Been there... (Score:1)

    by Anonymous Coward
    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.
    i'd use the ip addresses of your domain controllers if i where you. if not, a cracked name server might easily turn in to a completly cracked network...

    B. Johannessen (to lazy to log in)

  • Re:How about the "third solution..." (Score:3)

    by Anonymous Coward on Saturday June 02, 2001 @09:44PM (#180874)
    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?

  • Solutions (Score:5)

    by Anonymous Coward on Saturday June 02, 2001 @08:45PM (#180875)
    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

  • Been there... (Score:5)

    by Russ Steffen ( 263 ) on Saturday June 02, 2001 @08:28PM (#180876) Homepage

    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.

  • So, as you said, let's stick to the facts. Not that I'm a Mac or BSD fanatic, but BSD users are on the increase via MacOS X, which is heavily based upon NeXT Step (BSD based) and NetBSD, with a little FreeBSD thrown in for good measure. Now for some speculation. With Apple shipping MacOS X preinstalled, and with commercial apps being ported to it (tho many will use Apple's proprietary Carbon API's), etc., there could be some positive fallout for the other BSD flavors. Who knows, with Apple producing x86 Darwin stuff, we could see Apple move to x86 hardware and really take off.

  • I'm in the process of building a system that integrates Windows and Unix logon data. My environment currently includes Debian GNU/Linux, Microsoft Windows, NetBSD, Silicon Graphics IRIX, and Sun Solaris, and I hope to bring Compaq OpenVMS and Apple MacOS (pre-OSX) clients into the mix within the next six to twelve months. What makes a difficult project even more challenging is that I'm attempting to integrate file sharing as well as domain logon. The environment I'm building is in it's third generation.

    Getting Kerberos 5 clients to authenticate against AD is pretty easy and (for MIT Kerberos 5 and SEAM clients) well documented. See Windows 2000 Kerberos Interoperability [microsoft.com], Step-by-Step Guide to MS Kerberos 5 Interoperability [microsoft.com], and SEAM 1.0 Interoperability Documentation [connectathon.org]. You should be able to adapt the SEAM instructions to pam_krb5 on Linux, or you could use login.krb5 (which comes with MIT Kerberos 5). Note that Heimdal clients don't support DES-CBC-MD5.

    The biggest problem with Active Directory has nothing to do with Kerberos, and everything to do with getting directory information out to clients in the realm. For example, NetBSD doesn't currently use the PAM mechanism, and Solaris has a difficult time understanding Microsoft's somewhat peculiar schema. To this end, I've decided to use NIS to publish certain directory data to my Unix clients (user name, UID, GID, GECOS, home, and shell; group name, GID, and members), and revisit client directory access issues as the technology matures. And since I can't get SFU to install on my DC (the DC's DNS domain name and the AD domain name are different, and this causes problems for SFU's installer), I've resorted to creating the necessary auxiliary classes by hand and using some glue code to dump user and group information from LDAP into the relevant NIS databases.


    Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16

  • That's the other "his" point. Both Kerberos and NTLM require unique account names within an administrative domain and can't (easily) use DNs in the place of the User Principal Name or the SAM Account Name.

    And yes, the old (NT4) domain system was basically a flat file (the SAM database), but this isn't the reason behind the requirement for unique UPNs in Active Directory. Kerberos too uses a flat database, and there has traditionally been no way to partition a realm (that is to say, the entire realm is propagated among masters and slaves in Kerberos). The replication and partitioning limitations in Active Directory are derived from AD's roots in Kerberos, not NT4.


    Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
  • In mixed or native mode?

  • Ganymede (Score:5)

    by jonabbey ( 2498 ) <jonabbey@ganymeta.org> on Saturday June 02, 2001 @11:37PM (#180881) Homepage

    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 [utexas.edu] passwd validation suite.


    - jon
  • Besides... Maybe some other people have the same question and the same precicament, just not the time deadline and the lusers to deal with. Hell I for one am trying to bring all of our IT services into one conglomerated system rather than the (n) vendors we have out there doing this and that for us. I would like to set up one account on the Active Dir server, cascade it to the linux boxen and then hopefuly manage linux based pop3 email smb services winblows print services and so forth with one directory tree.

    It's a hope that's out there, but I feel I'm not the only one... just as the original ask slashdotter isn't the only one with this problem.. :-)

  • Re:Ganymede (Score:3)

    by Cato ( 8296 ) on Sunday June 03, 2001 @01:35AM (#180883)
    Also, have a look at the presentation at http://kodama.open-it.org/roadmap/index.html - this outlines how the OpenIT group is working on projects to integrate Ganymede with LDAP, both as a frontend protocol and backend storage system (Ganymede currently stores its data in memory). The main OpenIT site is at http://www.open-it.org/.

    It may also be worth investigating how you can get Win2K clients to authenticate against a Unix/LDAP server - in the NT world, some links to follow are http://www.citi.umich.edu/projects/singlesignon/po ster2.html (which has integrated NT's login process with the Unix/Linux PAM framework) and http://www.smartcard.ust.hk/tutorials/smartlogon2. htm (good set of links on GINA, the NT login DLL that can integrate with third party authentication mechanisms).
  • Another point to your response. Sir Distic (sp?) recently gave a talk about how to crack SMB using a man in the middle attack. If a malicious person is able to access your network, SMB provides little to no protection.

    Basically what happens is that if you set up a box to broadcast as another box windows systems will pass their encrypted login information. The malicious box then does an authorization request against the domain and can act as that user.

    Please not that if your system admin on a windows box uses a browser... isn't integrated browsers nice... you can point it at the malicious system and automatically have it try to access the system, thus not even requiring you to broadcast the malicious box as a resource on the network.

    Cute little toy to use with web bugs and another reason to block all port 137 and 139 traffic to the internet for those of you with internet connections.

    I know that Sir Distic (sp? again) released his code into the wild and while I haven't had a chance to look through the code, I have seen the program in action and can verify it works even in a "hardened" Windows environment.

    The problem isn't a bug in the system, but a design flaw within SMB, so the question is how secure do you want to be?

    Lando
  • The only problem with utilizing a non-MS KDC is that you can't use those tickets to access most Win2K-based services. Win2K services require the authorization data in the service ticket, which is essentially composed of group UIDs taken from AD. The Heimdal or MIT Kerberos KDC can't access or generate this data.

    It is possible to do cross-realm authentication between an MS realm and a non-MS realm, but then you need to perform an account mapping so that the MS realm issues the proper service tickets at the end of the referral chain. Happy happy, joy joy.
  • 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,
  • LOL. Only when an ERD is done...and how many NT admins do THAT on a regular basis? :)
    And when SYSKEY is enabled, it's STILL encrypted...even on the ERD and the repair directory. Plus, you still have to have PHYSICAL access to an ERD or the machine to do it.

    I didn't SAY the SAM wasn't easy to get. But I said you gotta have PHYSICAL access to do it. I don't know about YOU, but that's why I lock my servers (and the ERD in a safe therein) in a room.

    Listen next time.

    -Kevin, MCSE/MCT
  • Reread the readme.

    You gotta be an Administrator to run pwdump2.

    Normal users don't have that right. And since I'd be an Admin...I could just change the password myself in User Manager. :)

    Cheers.
    -Kevin, MCSE+I/MCT

  • Utter Bullshit. (Score:3)

    by Lt_Kernal ( 11104 ) on Saturday June 02, 2001 @10:18PM (#180889) Homepage
    Okay. Enough of this shit. FUD killing time.

    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 /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.

    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
  • Well, if you install SFU it'll define the attributes for you. You still need to fill them in, but you can do that by taking the existing information and creating a script to build an LDIF file out of it. Here's the populate script, just run it and it'll output the LDIF file. There's a windows command (sorry, can't remember it) that'll import that into Active Directory. HTH #! /pkg/gnu/bin/perl -w @ARGV = ("wuid"); while(){ chomp; ($wuid, $user) = split /:/; $id{$user} = $wuid; } @ARGV = ("passwd"); while (){ chomp; ($name,undef,$uid,$gid,undef,$dir,$shell) = split ':'; $dn="cn=$name,cn=users,dc=cec,dc=wustl,dc=edu"; print EOF; dn: $dn changetype: modify replace: syncNisDomain syncNisDomain: cec - EOF if (exists($id{$name})){ print BLAH; replace: employeeID employeeID: $id{$name} - BLAH } print FOO; replace: msSFUName msSFUName: $name - replace: uidNumber uidNumber: $uid - replace: gidNumber gidNumber: $gid - replace: msSFUHomeDirectory msSFUHomeDirectory: $dir - replace: loginShell loginShell: $shell - FOO }
  • Ok, how do you get code to actually paste right without /. messing up the formatting? Why can't I use <pre> tags? Argh...email me for the code. lopresto@writeme.com
  • LDIFDE it is. Don't know anything about CSVDE, but it might work too.

  • Very possible (Score:4)

    by Eimi Metamorphoumai ( 18738 ) on Saturday June 02, 2001 @08:38PM (#180893) Homepage
    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!
  • 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.

    IIRC if you use NTLMv2 this is not the case.

    Avoid supporting downlevel clients if possible (98, etc) and security will also be better.

    Check out:
    http://www.microsoft.com/technet/security/
    http://www.microsoft.com/technet/security/bestprac .asp
    http://www.microsoft.com/security/default.asp

    ...Microsoft is spending a lot of time and $$$ on their security issues, and information such as that within the web pages I have listed is being created as we speak.

  • Re:And I'd like to know exactly the opposite (Score:5)

    by stab ( 26928 ) on Saturday June 02, 2001 @11:40PM (#180895) Homepage
    Well, you could replace the 2k kerberos auth with MIT Kerberos ...

    http://microsoft.com/technet/win2000/rsvpker.asp [microsoft.com]

    And 2k clients could still authenticate with no problems, but you have a *NIX based KDC, with the obvious advantages that brings.

    Microsoft even publishes a step-by-step guide to doing this!

    http://www.microsoft.com/windows2000/techinfo/plan ning/security/kerbsteps.asp [microsoft.com]
  • the one master key that unlocks everything.
    Like I'd use my /. password for anything else that matters.
  • ...you can't even partition an AD tree. That means the entire database is transmitted to every server, even if their OU has nothing to do with that system.

    Somewhat true, yes. All changes are replicated to every DC in the same domain. A much smaller subset (the global catalog) is replicated to DCs outside the domain.

    Also know that in AD, when you edit an attribute in an object, the entire object is resent out to all the servers. Not just that attribute for the object.

    This is plain FUD. AD does indeed replicate at the attribute level. But don't just take my word for it, as you have obviously done with your misinformation, verify this yourself:

    http://www.microsoft.com/WINDOWS2000/techinfo/resk it/samplechapters/dsbh/dsbh_rep_mqeg.asp [microsoft.com]

  • PAM required all of the user IDs in /etc/PASSWORD, which means if you create a new user in LDAP (or AD) you will have to update your /etc/password files on all your boxen

    Huh? since what version? I'm using LDAP pam w/o /etc/passwd entries.
  • Ohh, and if you really want, I am half-way through a white-paper on this exact topic and feel free to email me for a copy

    The key here is "white paper". I saw three posts that summed up what to do in two paragraphs or less. But, our boy here is writing a white paper! Oooh, I get all tingly!

    in .DOC format, of course

    Ok, I know they don't teach this in the "Magic of Word Processing" VHS course, but you can click (using the mouse) on the "File" menu, and then select the "Save As" option. This allows you to save your documents in many of the formats that people use to communicate information such as "text" (an advanced format for which many WYSIWYG editors exist).

    I'm sorry, I know I'm being sarcastic to a fault here, but such a condescending post that lacks any real information, and whose humor is solely based on stereotype was a little thick for me. I suppose in sinking to that level, yadda yadda, but at least I feel better now.


    --
    Aaron Sherman (ajs@ajs.com)
  • Whats the text format that allows you to embed
    • binaries

      If your white paper requires binaries, I cannot imagine a case where giving a footnote to an FTP server would not be more useful than trying to embed the binary itself.

    • such as images

      Ah, now you want to select the "HTML" option when you save. Much more portable, and images are rendered much more cleanly by most browsers.

    • configuration scripts

      These are text to begin with. Again, though, I suggest putting these in an appendix of links to a Web or FTP server.

    • screen captures

      Special case of images, see above

    • packet dumps

      Text. See above

    • and the like?

      See above



    ASCII, was that it? Yeah, I'll jump right on that.

    Good. Best papers I've ever read were all text. "Substance before form".

    Plus, you dink,

    Quite called for. I'll try to rise above my initial comments.

    .DOC files are widely read by such great products like

    Some, but not even most .DOC files can be read in a mostly readable way by those tools. Saving to text or HTML guarantees a much higher likelihood of readability. That was the goal, was it not?


    --
    Aaron Sherman (ajs@ajs.com)
  • 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 [spdae.com]....

    --
    Aaron Sherman (ajs@ajs.com)
  • Making fun of slashdot on slashdot is passe. Kind of like telling knock knock jokes. Of course you were right MS does not play nice with others. I would like to know just exactly what kind of convolutions you had to go through and how well it worked. Are you going to post it on the net someplace?
  • If you really did this for a living you'd know that unified login is a standard in most enterprises.

    Get a clue.....

    Dave
  • They use something called Herderos. Dr. Wettstein posted a great article here [linuxnews.com] It's competition for AD that scales.
  • Well, I haven't done this against Active Directory, but at a previous job, I did set up Linux to authenticate against an NT Server. I used pam_smb. It took a bit of work, but it did eventually work. Keep trying, and eventually you will find a way to get it to work. It was easier to get Linux to authenticate against NT than the other way around.
  • Er, actually, I avoid learning about Microsoft software about as much as I can, but I believe that in 95 (not sure about 98) and I believe even some early SP's of NT, passwords aren't sent cleartext, but replayable hashes are sent in cleartext, which is about as bad.

    So you can't just log in by typing someone's password after stealing it, by you can write a program that'll send the replayable hash at the right time when asked.
  • I was beginning to think I was the only one who was able to figure that out. He actually did offer to help this guy, unlike the folks who simply state "Read the F______ Manual". Seriously, this is a complex issue; one that not too many people know how to tackle since it involves being open minded enough to actually understand how active directory works, as well as using other non-MS products. This may come as a shock, but a lot of people rely on Windoze to do their jobs. Yeah I know, sorry about their luck... It is just a shame some people feel the need to be holier than thou, instead of offering up some decent advice.
  • That works fine, but if I recall, that would use NTLM, which sucks with regards to security. Member server authentication is not dependant upon native/mixed mode.
  • Test it, create an OU, and make a user called "bsmith". Now create another OU anywhere else and try and create a user named "bsmith".

    Were the two OUs in the same domain? Because what you're probably seeing is the SAM account names or user prinipal names clashing: these have to be unique on a per-domain basis to support downlevel clients doing NT authentication (not to mention that it's at least a defacto standard for UPN and primary mail address to be the same).

    Then, given the accuracy of the rest of your post (No attribute-level replication? What are you smoking?), to expect you to get this bit right either is probably asking a bit much...
    --
    Cheers

  • Look into Radius authentication. Your AD DC's can act as Radius servers and your *nix boxes can act as Radius clients thus unifying your logins across almost any platform including a lot of routers/switches.

    forgey
  • Url to that user managing code is http://msdn.microsoft.com/library/techart/kerberos samp.htm

    I just tried this and it seems to work ok. But it requires specific Netscape's ldap client version that dates back to 1998 which isn't too simple to compile.
  • To whoever posted that first reply, grow up! The reason why Linux has had such trouble entering the market is because of short sited users such as yourself that have nothing more to say that "M$ sucks, Linux Rocks."

    You need to go back and read that post again. It was a joke. It was predicting what the rest of the thread would boil down to, making fun of your average ./ post.

    The incredible thing is that post was originally modded (+3, Informative).

    Gum "Can't PAM communicate with Active Directory via carrier pigeon?" bo

  • 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.

    Are you sure about that? pwdump2's readme file disagrees with you:

    This is an application which dumps the password hashes (OWFs) from NT's SAM database, whether or not SYSKEY is enabled on the system.

    And you don't have to shut down NT to do any of that. I'd be worried about anyone forced to administer NT who doesn't have pwdump2 or 3 and L0phtcrack handy...

    For the curious, the details on how pwdump does its magic:

    It uses a technique known as DLL injection. In general, one process (pwdump2.exe) forces another process (lsass.exe) to load a DLL (samdump.dll) and execute some code from the DLL in the other process's (lsass.exe's) address space and user context. In this specific case, once samdump.dll is loaded into lsass, it uses the same internal API that msv1_0.dll uses to access the password hashes. This means it can get the hashes without doing any of the 'hard' work of pulling them out of the registry and decrypting them. The program neither knows nor cares what the encryption algorithms or keys are.

    And, of course, for anyone who's not familiar with it, pwdump2 is GPL'ed...

    Gum "All your SAM are belong to pwdump" bo

  • Re:Resist your users! (Score:5)

    by gumbo ( 88087 ) on Saturday June 02, 2001 @09:00PM (#180914) Homepage
    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.

    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

  • For a full explanation on how to make a database scale to inifitum, read http://www.geocities.com/feromus/db.htm
  • To learn how to make distributed databases to scale without limits, read http://www.geocities.com/feromus/db.htm
  • 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 get paid to do something that I can't figure out!!! Instead of doing some real research, will you help me come up with the information before my deadline??? Please??? I really want to play Tuxracer instead of doing actual work!
  • Just change the formatting to either "code" or "plain old text" instead of HTML.

  • Password authentication should be simple, but... (Score:4)

    by Trepalium ( 109107 ) on Saturday June 02, 2001 @08:47PM (#180920)
    The major problem you'll face isn't authentication (which pam_krb can handle), it's the fact that the stock Microsoft Active Directory LDAP directory doesn't have the needed schema to support UNIX clients without the Services for Unix 2.0 package (in which case, you could just use NIS). To complete the package, you need to have both nss_ldap and pam_ldap, however the format of Active Directory doesn't match the format that nss_ldap expects.

    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.

  • as opposed to the hashes unix keeps in /etc/passwd, which usually 33% can be obtained within hours, half within days?

    I don't believe you. Prove it. Here's something I pulled at random from /etc/shadow. I don't know what this password is; obviously, I can check any answer you give me. It was chosen by someone who is not particularly security-conscious. I challenge you to break it: $1$s3m2axu1$QqizKegYZh5JLyXaCi/47.

  • To the dense: It's a joke.
  • Wow..a whole three guys? At my company (not to be named, but the smaller of the two national railroads in Canada who's initials end in P) we manage 212 NT servers, 14,000 users, and about 2000 printers with three guys. This is not a joke or exageration.

    On top of that, we have a change management process that requires a minimum of three days notice for any outage. Try handling a large NT environment with that sort of burden.

    If you feel overworked, I invite you to come up north and experience my world :)
  • There are two forces working when you want to keep your network secure: technology and psychology.
    At one end, to be ultra-secure, you could go really nuts, have each machine use a different password, have each user change their password every month, require all passwords to be mixed case including numbers and letters, and so forth.

    This, of course, could reduce your security, because your users will stick post-its to their monitors with their passwords on them, or email the passwords to themselves at Yahoo so that they have a record in case they forget.

    You can't forget the human element here, because the human memory system is based on entirely different principles than a computer's is. People use all types of tricks to aid their less-than-perfect memories, the strategies they use in response to a paranoid admin's security policies may end up making the system much less secure when the human element is factored in.

    Furthermore, its a mistake to think that this can be totally solved by HR policies and proper education of the user, because you might be setting up a system that can't be used by many people unless they introduce external memory aids (which are security risks). It would be as if (hypothetically) you were a record company heavily overcharging for CDs of a popular music "artist" or group, but complaining when people trade mp3s of the songs you refuse to sell them at a price they are willing to pay. Beware of your own rules and realize how they can sometimes encourage users to behave in ways that are antithetical to your ultimate goals.

  • I see. An AC wrote earlier
    "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."
    Will that help with the authorization problem in this case?

    Yeah, cross-realm stuff is strange in W2k. Sigh...

  • You can always try setting up a UNIX-based KDC, running Heimdal [pdc.kth.se] krb5 implementation. (Don't use that one from MIT... ;-) Make sure to only allow console login on that machine, and turn off all services you don't need. It will be the only computer where all the passwords are stored, so if it gets cracked, you're in big trouble. I don't know about you, but I'd rather trust my password database to a properly managed Solaris machine than a W2k machine.

    Now, having UNIX clients authenticate to that server is really straight-forward. Just install Heimdal and kth-krb [pdc.kth.se] 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.

  • Could you send that DOC my way? I emailed your Hotmail address and got no response, thought maybe your box was flooded =) mack at rebellands dot net
  • 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
  • I think the windows command he is referring to is either CSVDE or LDIFDE to do a bulk import. Run these from the command line to get help.
  • Netegrity siteminder is indeed focused on securing web resources. You can, however, write cusomised add-ons. It all depends on whether or not you have time for this - knowledge won't be a problem because their docs are great. Some more information on what applications you actually want to have SSO for (which is your goal, I understand), would be useful here.
  • Comment removed based on user account deletion
  • Comment removed based on user account deletion
  • Comment removed based on user account deletion

  • Comment removed (Score:4)

    by account_deleted ( 4530225 ) on Saturday June 02, 2001 @08:04PM (#180934)
    Comment removed based on user account deletion
  • And you can use ZEN Works to distribute applications and enforce Windows User and Workstation Policies. ZEN 3 comes with a remote-imaging service that allows you to specify which workstation objects in the NDS database (tree) should get which workstation images, and have them re-imaged automatically at a specified time. And for you Linux nuts, it does this by installing a small Linux partition to the hard drive, booting from Linux, and then receiving the image over the network.
  • Has anyone heard of any awards that AD has won?

    Novell's eDirectory has won Product of the Year in 2000 and 2001 for their directory services from Network Magazine.

    I am looking for some more comparisons between the two.

    Read about it here: Novell eDirectory Named Product of the Year [novell.com]

  • The kerberos protocal for win2k IF you are running an all win2k network (no NT4, 95, 98, etc..) then it is very well encrypted and unless someone cracks a password (and only gets access to what that USER can access even then) they are not getting in. To crack said password you would have to have a SH*TLOAD of computing power (see bovine project). To steal the password you beat up the user.. but you ain't gonna snoop it.

    Yes, you are correct, I doubt that anyone will bother to crack it. It is so much easier to go directly at the server to find a hole or backdoor. :-)
    It seems to me that all the different divisions of Microsoft need to work a bit more together in terms of discovering what happens when they put all their programs together as one package(win2k).
    Like what services are installed as default on a Win2k server. Sure it's easy to install, but if you don'k know your win2k, the server is wide open for everyone(kinda like my old neighbor)

    --------
  • I know that the IT guy at my office was looking into Netegrity's [netegrity.com] Siteminder product. It seems to be centralized more on web application, and I know it does cost, but it might be what you need.

  • Re:How about the "third solution..." (Score:4)

    by Xross_Ied ( 224893 ) on Saturday June 02, 2001 @10:27PM (#180939) Homepage
    I have not looked into Novell stuff for about 6months, but I think you are mistaken..

    e-directory (your name NDS) is NDS that can run on NetwareOS, WinNT/2K and Linux..
    a) On WinNT/2K it actually replaces domain/AD as the authenticator.
    b) on Linux it replaces the password file by using PAM modules to redirect authentications to NDS

    What you are thinking of is DirXML a directory synchronizing daemon that maps parts of AD to NDS and vice-versa. IMO it is the slickest software from Novell since Netware 3.11 came out.

    You create the mapping of NDS schema to/from AD and you can tell it what part of (container / organizational unit) your NDS maps to what part of AD. You are still running two directories which are being synchronized at an interval you decide. What makes it kick ass is the schema and attributes synch is all visual, point and click.
  • Better than the quality of Microsoft's support. As an MCSE, I've had to deal with these wonderboys. Most of them couldn't solve an issue with the answer right in front of them. At least in the Linux community, you have resources like /. that will usually provide you with a direction instead of please tell me your credit card number please.....
  • 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
  • Just my $.02 worth of experience. Code to read user/group properties, modify group membership etc. is very simple under AD using COM. Trying to modify the Active Directory schema, -- to add custom attributes to each user object, for exmaple -- is a little more difficult. Not because the task is complex, but more because of a lack of detailed documentation. I did this when I was attempting to implement a "Unified-cross-domain-web-sites-login" thingie. Sorta like was MS Passport does...
  • >Sure it's easy to install, but if you don'k know your win2k, the server is wide open for everyone(kinda like my old neighbor)

    Where *exactly* did you say you lived again?
  • hell, the poor bastard is probably in way deep and just seeking a shoulder to cry on. we've all been there . . cut him some slack.

  • You wrote,
    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.
    What most people do not understand is that Kerberos should not be used for all authentication. If you are root level user, then you should never use such authentication. And you should also ensure that any critical systems do not accept such autentication. Kerberos is great for the masses, it's nicely done, but it's not a full replacement for all your password vows.
  • You're kinda slow, aren't you. The first reply is MAKING FUN of people who do what you're bitching about. Sit down, shut up, and read it again.
  • Yep I screwed up (hey, it's been a while since I had to deal with that crap), but that doesn't take away the validity of the rest of my post. MS password encryption is simple to break. It really only keeps honest people honest.
  • Yeah moron, I know it's standard, and I also know it's STUPID. Just like you.

  • Resist your users! (Score:3)

    by brash ( 322082 ) on Saturday June 02, 2001 @08:52PM (#180949)
    OS flame wars aside, unifying your logins is just a bad idea, from a security perspective. And if you're not concerned about security, then you may as well do away with passwords on your network entirely. You want to force them to use different passwords, and you want to force them to chose good passwords using some sort of password filtering program/library like cracklib, or if you must use NT, passfilt.dll (available in SP2 and later).

    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... :)
  • Let's play nice and allow NT machines to logon to Linux Domains and use Linux shares!
  • the link to the project is dead, search of site for kerdap yields 0 entries... where does it live now?
  • Sure does:

    NT4 SAM redirection
    AD syncronisation
    Native *nix PAM authentication
    LDAP3 for the rest

    not bad eh .. also it's been out for years, stable as anything, runs on multi-flavours of *nix.. and it's free to developers.

    Oh - and it scales like way big
  • I would have to agree with weakethics. Having been a card-carrying MCSE and CNE I can tell you that the best way to manage any NT/2K network is to put a Novell server at the root of your tree, and run NDS. I only have about one solid year with *NIX (GNU/Linux, Solaris, and FreeBSD), and so have played with this only for fun. On my network (RH7.1, Sol8, NW4.2SB, NT, 2K servers with DOS, 9X, NT, 2K, RH, Mac, and OS/2 clients) I had it installed and configured in about 2 hours. The only system I couldn't get it to work with was BSD, but given the time to research and hack at it, I am sure it would work. I don't know how much faith (read: job security) I would put into a network relying on Win2K for all authentication. Novell has been in the directory game for a long time and supports industry standards. They also have a history of reliably taking poor MS authentication methods and replacing them with solid, functional code. With NDS you can partition and replicate the schema with ease, not so with the MS attempt. I would seriously consider the NDS approach, and as far as your deadline, it is better to be late 2 weeks and functional than lying down on-time. Just my 2 cents, hope it helps a little.
  • if you actually read this post you are oficially a geek. Most people's brains turn off when they see something like "pam_ldap/pam_krb5 Authentication Against Active Directory?"

    That's cool shit though...

    It's 1:15 am my time PST, on a saturday night... doesn't anyone go out anymore?

  • Re:How about the "third solution..." (Score:4)

    by apachetoolbox ( 456499 ) on Saturday June 02, 2001 @11:57PM (#180956) Homepage
    Novell has already made a pam modules for NDS. Just install NDS for linux/solaris on the server and copy the PAM module over. Problem solved. You can also use DirXML to sync an AD "tree" with and NDS tree, so in turn you can login to the tree and have the user object on the AD tree.

    I use the term tree with AD loosely; understand it that AD isn't truly a hierarchical system. It's a flat database just like their old Domain system. Don't believe me? Test it, create an OU, and make a user called "bsmith". Now create another OU anywhere else and try and create a user named "bsmith". You can't. Seriously look into Novell's NDS as a directory solution, you can't even partition an AD tree. That means the entire database is transmitted to every server, even if their OU has nothing to do with that system. Partitioning a tree keeps the traffic to a minimum while still replicating to other specific servers for redundancy. Also know that in AD, when you edit an attribute in an object, the entire object is resent out to all the servers. Not just that attribute for the object. AD is still not even remotely close to NDS.

    NDS runs on Netware, NT, Win2000, Linux, Solaris.
    AD runs on Windows2000, and to really use it all your workstations have to be Windows 2000!

  • He is right. If you have a mixed network and want single user/shares management then NDS is the way to go. I love open source but that does not mean that there is not a good paid for choice too. Novell is good software. And as far as file/print sharing they are still the fastest bang for the hardware out there...

  • I've pondered doing the same thing on our network. But modifying the schema in ADS seems a bit too daunting a task. Perhaps if you migrated your user accounts to a samba server which functions as a PDC you could have all your users stored in OpenLDAP and have authentication occur through pam_ldap.

    I don't see why it wouldn't work, you may have to make some slight modifications to samba, and/or OpenLDAP's schema (_MUCH_ easier than modifying ADS!). Anyway, just a thought. Give me a month or so and I'll have a whitepaper on it...hopefully :)

    "We have nothing to fear but... ourselves, oh, and running out of good beer."

  • For the brave trying to make an AD out of openldap (haven't tried that myself) heres a link to the schemas: http://www.unav.es/cti/ldap-smb-howto.html also, for those who need schemas for unixusers into ad I would guess that a good start is to look at the schemas supplied with openldap and use them as blueprints.

    Tarjei

  • 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.
  • Go out? What is that? I go out of the server room every now and then to grab a snack. Does that count?

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close