Slashdot Log In
Linux Authentication Against Active Directory
Posted by
kdawson
on Fri Aug 08, 2008 11:55 AM
from the likewise-i'm-sure dept.
from the likewise-i'm-sure dept.
Bandman writes "For a while now I've been looking for something to integrate my Linux/Mac corporate environment with Windows Active Directory. I was hoping for centralized authentication at best. As I found out, Likewise Software has produced two products, the free Likewise Open and the commercial Likewise Enterprise. Both of them provide much more than just a centralized repository for accounts. I wrote a review of Likewise Open, but I don't have enough experience with Active Directory to really do justice to Likewise Enterprise. If you've been trying to integrate the Linux and Windows worlds, this could be the easiest way to do it."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
And if you act now... (Score:5, Informative)
Re: (Score:2)
enough with the lame tag! (Score:3, Insightful)
Stop with the signed [slashdot.org] tag already!
Re: (Score:2, Funny)
This is a review? (Score:5, Insightful)
Posting in your blog that you logged in with AD credentials is a review?
What is the downsides. How does it compare to other authentication systems, such as eDirectory, or Open LDAP? How is it any different from just using Samba, or some of the other tools that have been around for years. My Redhat EL 3 server had the option to authenticate against AD. How is this better? How is it better than using Microsoft's Services For Unix and NIS?
Does the directory information get carried to the new system? (Profiles, groups, mapped drives, printers, etc) Do you have to designate special groups to allow logging in? There is way more questions that I would like to see answered in a "review".
What capabilities does the Enterprise edition allow that the basic does not, what is the price, how difficult is it to move a currently running system, and all its users and permissions..
A blog post from someone that admits they don't know much about AD in the first part of the review doesn't really count does it?
Re: (Score:2)
"How does it compare to other authentication systems, such as eDirectory, or Open LDAP?"
Speaking of comparison's and Openldap, has a fix been made that will allow Linux workstations authenticating with Openldap to lock their screens, and be able to "unlock" them?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Well I was going to provide a link to the bug, however I didn't bookmark and sifting the thru the results is daunting.
It's been a few years since I last tried it, will give it a go again :-)
Thanks for the helpful and friendly responses.
Re: (Score:2)
Dazed, btw not against AD, Specifically Linux workstations authenticating against Openldap on Linux server.
I'm giving it a go again as we speak. Already have slapd setup, so just editing nsswitch, and pam confs.
thx again :-)
Re: (Score:3, Informative)
I have fiddled around with Windows/Linux integration for central authentication and found that the only alternative TODAY that works acceptable is to use the "Windows Services for Unix [microsoft.com]" (SFU) add-on for Windows Server. And you can download that from Microsoft.
It is possible to set up Linux as a LDAP server and with Samba as a domain controller for Windows, but currently it's tricky. I haven't done any digging in Samba4 yet, so all my experience is from Samba 3.
To me it seems like there is a lot of work to b
Re: (Score:2)
Just an update - SFU is now built into Windows 2003 R2 and Windows 2008. And the AD schema extensions now use the standard RFC2307 attributes rather than the SFU specific ones.
Re: (Score:2)
Welcome to Slashdot!
Re: (Score:3, Informative)
Nothing. It is using Samba.
Re:This is a review? (Score:4, Informative)
Samba isn't AD support, it uses the old method of logging in that was used with NT4, the name currently escapes my memory.
Samba does work with AD. But there is more than one technology that makes up the whole of AD (LDAP, Kerberos, DCE-RPC/MSRPC).
I believe the NT technology you are referring to may be NTLM or LanManager.
Parent
Re:This is a review? (Score:5, Informative)
You're talking about a Samba PDC. That uses old NT4 technology, not AD. But as a member server we support AD completely. In fact the current Likewise code is based off winbindd (part of Samba).
Jerry Carter, one of our release managers works for Likewise and supports it. It's open source too (at least the low end version is).
Jeremy.
Parent
Re: (Score:2)
While I don't know if they've hired a PR company, I can assure you that my blog entry isn't astroturf. I'm just a guy who finally found a completely painless way to get this done, and I've been trying for a long time. No astroturf here, I promise, In fact I'd never even heard of the software till I saw a submission on reddit the other day. It just worked so damned flawlessly and immediately that I thought I should tell other people about it.
but... (Score:5, Informative)
Re: (Score:2)
But why authenticate to fragile poorly managed MS-ADCs?
Why not setup a robust LDAP network on native Linux/UNIX and call it a day. Have 6 continuous years of service up-time on my service. Average per node is a few minutes per year, 9/10 fully planned. Maintenance, I do this part time. Highly automated and linked to HR including bi-directional password sync.
In fact, it feeds AD. Created in LDAP first, an admin enables AD including email if needed. All data is 100 in sync.
Aim small, get small. 18000
Re: (Score:2)
Because the tools are excellent, and it's been a very reliable system for quite some time.
I hope the editors got paid... (Score:3, Insightful)
Likewise software. (Score:5, Informative)
My $boss looked at this likewise software a while back, he didn't buy into it. He started listing off the features, and what all you could do with it. After he was done, I politely said, "Yeah we are doing all of that with our stock RHEL+Samba 3 systems, just fine. There's really no need to buy Kerberos+LDAP+Samba support from another vendor, that is why we pay Red Hat."
After I looked at their site, the only new value I have seen from this product is the graphical management console. On the other hand, I can use the compmgmt MMC snap-in to manage a properly configured Samba 3 server just fine.
Re:Likewise software. (Score:5, Informative)
It's just like buying Red Hat support; you get the backing of a company that employs the people who are developers for that project. With Red Hat you get a bunch of kernel developers and Andrew Barlette (another key Samba developer). You can't get better support for your money than support from key developers. Also, it enables the developers to work on open source projects as a day job, too.
Parent
Re: (Score:2)
No, I was not aware of the relation between Samba developers and Likewise Software. But then again, I am having a difficult time finding reference to the Samba project on Likewise' website [likewisesoftware.com].
Just to clarify, I am not against supporting Open Source developers with monetary incentives. I just wanted to point out that 99% of the Likewise solution, does in fact, come from the Samba project. For whatever reason, Likewise is not really advertising the fact that what they are selling is Samba support.
Personally,
Bogus Review and Sales Pitch (Score:2)
Re: (Score:2)
Even for experienced Linux admins, Centrify is really nice. We use it to provide authentication for our cluster.
kerberos works great (Score:2)
You can authenticate from a linux machine to AD using the MIT kerberos client. There are plenty of HOWTOs about how to configure that. Plus you have SSO for webapps, databases, ssh and about anything you can think of. And on top of that, the identity of the user is propagated to all the machines you Single Sign In with forwardable tickets, and though the tiers of mult-tier applications (Frontend -> Middletier -> Database - every tier knows who the user is). Kerberos is definitively the way to go in an
The easiest what? (Score:2)
One would think that "The easiest way to do it" would be to install Winbind [samba.org], LDAP [yolinux.com] or Kerberos [scottlowe.org] and use those to authenticate against AD.
The advantage here is that you're dealing with free software, included and supported by default in most Linux-based operating systems, and in many cases integrated so tightly that you only need to run one command and tick a few check boxes to make it work.
What does this third party solution add to that besides the $250 per seat price tag?
Re: (Score:2)
The word "supported" actually meaning something?
Re: (Score:2)
Yes, but "We give you a telephone number where you can wait on hold before being transferred to a call centre run by the company which bought the company which bought the company which made this product where all of the people you will speak to only know how to support our new competing product which we would really rather you buy instead of continuing to use what you already have and if you don't like it you can go screw yourself" isn't always what I want "supported" to mean.
I prefer that "supported" mean
If you REALLY want to waste money... (Score:2)
Heh. Here at my work, we're using something called Vintela. Interesting that it hasn't been mentioned at all here.
I asked, "why are we spending all this money on Vintela when I can set up AD integration with Linux' native tools?" and the answer was "because we've already paid for Vintela."
Since the Big Boss is an avid golfer, I'd be willing to make a small bet that the Vintela salesman is too....
It isn't a "bad" product -- at least it actually works. But their advertising really offends me (in which M$ K
Security... (Score:2)
What i always find, when doing a security test against an AD network...
If you root the DC, the network is completely owned...
If you root a workstation you can usually get access to the DC from it, hijack a logged in user, crack cached passwords or keylog as someone logs in (and then break something so an admin has to log in).
If you get the password hashes, they will usually be Lanman and NTLM... Lanman is laughably weak and trivially cracked, NTLM is better but still much weaker than the encryption used on
Re: (Score:3, Insightful)
If you went to a car dealership, and you wanted to buy an automatic, what would you do if the salesman said 'Oh, get a stick shift, you've got much more control'? - and then he refused to sell you a car with an automatic transmission?
Re: (Score:2)
Fuel cost maybe (depends on how you drive) but repair costs? I have put over 200,000 miles on my v6 auto engine and transmission. The trans is electronic. Other then getting the trans fluid changed every 30,000-40,000 miles it has not cost me anything. No repairs no issues. If it is was a stick, I would have gone through a few clutches (at least) by now along with getting the fluid changed. Actually the engine hasn't been too bad either, besides plugs and wires at 104,000 and just last month, I have but in
Re:Linux authenication aganist....can not connect (Score:4, Insightful)
Ever work in a large environment? Its much easier to have one point of authentication and configuration. Do you want to deal with managing users (change passwords, disabled accounts, etc) on 8 different systems? I sure don't. Things will get forgotten, and accounts that should be disabled will not be.
You obviously haven't used AD very much, because it is not just an authentication system. It ensures policies (drive mappings, configurations, proxy settings, MS office behaviour and defaults, security standards, etc), deploys software and printers to users and computers
Parent
Re:Linux authenication aganist....can not connect (Score:4, Insightful)
"...it is not just an authentication system. It ensures policies (drive mappings, configurations, proxy settings, MS office behaviour and defaults, security standards, etc), deploys software and printers to users and computers"
Of what use is this in anything other than a Microsoft Environment?
How does AD "deploy software and printers" to anything that isn't a Microsoft Environment? And why would you even want it to?
So, from a network viewpoint, AD is just an authentication system. The rest is worthless in a heterogeneous environment.
[Proxy settings are useful].
Parent
Re:Linux authenication aganist....can not connect (Score:4, Insightful)
Parent
Re: (Score:3, Interesting)
It isn't Linux that I am concerned with. It's the entire datacenter.
I work with Solaris. We sell expertise. Used to be, our network was fine - no issues. Then, we had a merger. All of a sudden, the IT dept has to support Windows. What happens?
AD is deployed. This makes Windows happy happy. Not so happy on the Unix front. MS DHCP isn't quite right -- insists on resolv.conf entries that won't work. I can type machine.whole.damn.domain, works. Of course, if I could *use* AD, I would be only typing "machine". A
Re: (Score:2)
I'm late to the party, but from the documentation I've read (~300 pages so far), all of these policies, printers, etc are able to be added to linux machines using Likewise Enterprise. It' essentially extends the management environment to Unix machines
Re: (Score:2)
Sure, but AD isn't the only solution to that, and Kerberos+LDAP+Samba (as the parent poster is using) is an adequate solution (and may be a superior one if you have more Unix to worry about than Windows).
Re: (Score:2, Informative)
Authenticating to a Linux LDAP server is nice for central authentication, but it misses out one of the A's completely, and does a shit job on the remaining one.
Authentication - Easy to do against LDAP.
Authorization - Nope, not there, unless you're going to run Kerberos as well. Then you run into compatibility issues and integration nightmares.
Accounting - Horrible. Almost as unusable as the Event log.
Plus, you don't get any of the nice features of AD. Group policy is great for managing lots of computers
Re: (Score:3, Informative)
AD *can* store any arbitrary inform
Re: (Score:3, Informative)
I hate to break it to you, but LDAP is not a directory system. It is a directory protocol. AD provides an LDAP interface. So your directory system can be structured and provide storage in the backend pretty much any way you want. Microsoft, for instance, uses Jet for storing their data, and X.500 for structuring it. But if you wanted to build your directory using post-it notes and robot, then fine, as long as you provide an LDAP interface, you're an LDAP directory.
I could build it out of unicorn farts, I'm not arguing that. The fact remains that any of the Linux LDAP implementations are Directory Servers.
AD *can* store any arbitrary information with schema additions. So if you can query LDAP on the Linux side for window manager policy, and you can come up with a schema that represents that policy, go ahead, store it in AD. Mac people have been doing this for years, although Apple would prefer that you use their Open Directory system.
Again, I'm not disagreeing with you.
Also-- AD uses Kerberos. How do I know? Because I have Linux machines (MIT Kerb), OpenBSD machines (Heimdal), and Macs (MIT/Apple Kerb) all authenticating against our AD. There are some little oddities here are there (your machines have to support Microsoft's cipher-- which I believe is now installed by default on all recent Kerberos distributions), but in general, it works surprisingly well. For me, on Linux machines, the trick was learning the ins and outs of PAM and winbind. After that, it was easy.
And I'm sure that AD uses Kerberos as well. I've got stacks of books about it, traffic dumps, whatever you need. I've got more proof that AD uses Kerberos than people have that the moon landing was fake.
Anyway, if you're expecting LDAP to provide authentication, you're mistaken about the purpose of LDAP. Think of it as a fancy phone book. What you need are a lock and key. Also-- accounting? For that, you want a piece of logging software. Microsoft supplies all of these things neatly packaged together, and if you don't want to bother with the details, then it's a decent choice. But don't confuse the two, because LDAP only provides a subset of the services that AD does. Complaining that LDAP does a "shit job" at authentication and accounting is like complaining that your tires do a "shit job" of steering. Well, duh.
This is where I disagree with you. LDAP does a wonderful job of authentication. I know that it's not actually doing the authen
Re: (Score:2)
an LDAP backend to an authentication system
You used that phrase several times so I'm quite sure it's what you meant to say, but it's completely nonsensical. How can you have a Lightweight Directory Access Protocol backend? It's like saying your website has a TCP/IP backend.
Re: (Score:2)
Except you should be doing it against Kerberos ...
Actually, LDAP *should* be used for authorization, and can be quite easily, with or without Kerberos ...
Actually, my Heimdal KDCs integrate with my OpenLDAP server quite nicely, storing all their information in the directory server (in the same entries used for LDAP authorizati
Re: (Score:2)
Re: (Score:3, Insightful)
As of v4.11 of Novell's NDS (now eDirectory), NDS was a far superior system for man
Re: (Score:2)
No kidding, I've been doing this for, oh, three to four years using nothing but pam-krb5 and nss-ldap. Slashvertisement of the worst kind. The "review" is nothing of the sort, just, "hey, want AD integration? Use this!"
Re: (Score:2)
I think the big thing that likewise tries to promote with their product is that it's a one-stop configuration for a variety of UNIX and UNIX-like operating systems.
I know it's possible to set up linux machines to do SSO against AD with krb5 and pam and everything else, but it's not exactly an easy process. with likewise, it's a really quick process to join an existing AD.
i've used the likewise thing - i
Re: (Score:2)
Please elaborate.