LWN: Comments on "Authenticate Linux Clients with Active Directory (Technet)"

idmap_ad, idmap,rid

tarvin — Sun, 23 Nov 2008 12:37:15 +0000

I just downloaded the source RPM for RHEL 5.2's latest Samba package. In the spec-file, both idmap_ad and idmap_rid are mentioned in the configure command. But this could be something which is relatively new.

Authenticate Linux Clients with Active Directory (Technet)

jra@samba.org — Thu, 20 Nov 2008 04:42:41 +0000

Sorry you've found the 3.2.x series buggy, we are aware of a couple of issues that we've fixed in the next 3.2.x release (due out very soon). Please give it a try and give us any feedback on any bugs you find. There are many improvements in winbindd in the 3.2.x series, so long as you find it stable enough for you.

Jeremy.

Authenticate Linux Clients with Active Directory (Technet)

dps — Tue, 18 Nov 2008 16:00:45 +0000

Yes, I have done "split horizon" DNS configurations. I actually made the "real" and "fake" (aka public) DNS servers separate boxen. However if you broke into the front end machines you could access the "real" DNS information and reach some (limited) things which were otherwise inaccessible and secret.

The add zone entry attacks a serous problem: the proposal not enough. Many windows clients will refuse to work if they can not do zone updates. I think the best solution would be an option which allows "updates" provided they make no change the zone whatsoever. AFAIK no DNS server has such an option.

Given that updates are allowed it is probable that worms can do malicious ones which seriously comprise a site's security. AD also looks like making owning a single machine close to owning the entire network and the two should be very different.

NIS+ and secure RPC does have fairly convincing proof of knowledge of secrets in most directions, unlike DNS.

FYI if you can run SELinux in enforcement mode it is possible to nsplginwrapper's player component a very restricted environment. If access was limited to browser_tmp_t files then trying to examine the installed software or call home would yield "permission denied, your unauthorised activity has been logged".

Authenticate Linux Clients with Active Directory (Technet)

jeleinweber — Mon, 17 Nov 2008 17:17:36 +0000

In Fedora and Ubuntu, there is a trend toward using "Likewise Open" for simple Linux -> AD integration. It's OK if you don't need to control the UID/GID assignments in detail; for that you either pay money or do configuration work.

Authenticate Linux Clients with Active Directory (Technet)

jeleinweber — Mon, 17 Nov 2008 17:11:01 +0000

The caching point is important; straight LDAP is too heavyweight for the volume of getgrent() and friends calls typical Unix applications make. The classic caching solution for the non-winbind folks using straight LDAP is to run "nscd".

Authenticate Linux Clients with Active Directory (Technet)

jeleinweber — Mon, 17 Nov 2008 17:07:07 +0000

All good, valid cautionary points. A couple of supplemental remarks:

Most serious organizations these days run "split horizon" DNS; the external view from my DNS servers omits SRV records, RFC1918 private subnets, and quite a few other things I don't want to leak. My outside DNS servers run Linux with SeLinux in enforcing mode precisely because I don't trust Microsoft domain controllers to be that exposed.

To avoid the "add zone entry" attacks against Microsoft DNS you have to deny dynamic DNS updates from anything except domain controllers and DHCP servers. The thing you lose is the ability for Microsoft clients to correctly describe DHCP IPs for multihomed workstations. But how many of us have workstations with multiple simultaneous wired or wireless network connections at the office?

Until things like Google Chrome get more popular, our browser plugin confinements are pretty much firefox + noscript or virtual machine guests. Though IE7 on Vista does run with reduced permissions, e.g. it can't even write C:\TEMP, much less C:\Windows\System32 or the registry.

Authenticate Linux Clients with Active Directory (Technet)

cortana — Mon, 17 Nov 2008 13:29:41 +0000

I can sign into my email and web sites using my SSH public key? How?

Fedora?

ceplm — Mon, 17 Nov 2008 09:32:16 +0000

Apologising for "high on crack". Apparently the issue is more complicated than that.

Fedora?

ceplm — Mon, 17 Nov 2008 09:18:12 +0000

system-config-authentication is present in RHEL4, which means that this was present in Fedora 3 (at least). And yes, setting up authentication of the client against central LDAP/Kerberos/Samba/something-else-I-forgot is dead easy -- just check one checkbox and fill the name of the server.

And yes, it is run during firstboot, i.e., just after the installation.

I believe other distributions have something similar, so not picking against them, just that the Microsoft guy really is high on crack. Not mentioning that AD is based on Kerberos, which is not exactly their invention.

Authenticate Linux Clients with Active Directory (Technet)

niner — Mon, 17 Nov 2008 08:25:43 +0000

openSUSE let's you set up both NIS/LDAP/Windows Domain authentication on
clients and an authentication server running openLDAP and Samba using
yast. It's fairly easy, too. I only wish I've found out about that before
setting everything up manually.

Very useful comment

ctg — Mon, 17 Nov 2008 06:16:58 +0000

This comment was actually far more interesting that the original article (together with a few of the other more information rich comments in this thread).

In instructions, I like a bit of explanation about why I am pressing a particular button, not just the buttons to press (which is the biggest fault of the original article).

Authenticate Linux Clients with Active Directory (Technet)

drag — Sun, 16 Nov 2008 22:10:44 +0000

> The problem was that RHEL doesn't include this. And I'm guessing they think there is too little market for it.

Well for the market Redhat is in it's all heterogenous enterprise arenas. Places were Microsoft isn't very common.

So there is going to be a lot of legacy software and legacy operating systems that probably are to difficult to get running with secure network authenication.. either that or your dealing with corporations that take things seriously and already have a extensive kerberos and network directory system in place.

Either way to integrate Linux into a situation like that is going to require significant amounts of in-house expertise and customization... which those larger corporations are going to have. And compared to other Unix or legacy systems that Linux tends to replace Linux distros are much easier to deal with for the most part.

--------

But saying the market for having a easily integrated secure domain and desktop is small is 100% wrong. In terms of numbers the amount of people needing these features to deploy their desktops vastly outweigh any other server market.

This is Microsoft's bread-n-butter. This is how they make their money and is one of the major reasons, if not the major reason, why their server platform is the #1 most popular in the world in terms of cash and numbers.

The thing is is that Microsoft has grown up with their customers, and continue to do so. They provide products that favor small-medium businesses and as those businesses grow to larger and larger businesses they continue to purchase Microsoft products.

That's like saying the desktop arena is small potatoes because Linux doesn't sell well. And, in fact, this is one of the major problems when it comes to Linux desktop... whenever you have a Microsoft domain with Microsoft servers and Microsoft software Linux will always be a PITA, will always be second-fiddle.

Authenticate Linux Clients with Active Directory (Technet)

avik — Sun, 16 Nov 2008 22:01:10 +0000

The crack comes from building your own packages on RHEL5. The whole point of RHEL is you get support, but by building your own RPMs you become unsupportable.

Certainly, the article could have been said, "I could not manage to get authentiation to work against AD with samba. I placed a support call with the vendor. Later that day, the vendor called back and informed me this is not a supported configuration, and asked me to file a bug report so that it could be supported in a future release."

Of course, the response would have been, "the author is on crack; that's how you work with closed source software where you are completely on the mercy of the vendor. The beauty of open source is that anyone can spend five hours with the debugger to figure out what the problem is and then recompile from source to get it fixed."

Less cynically, there is no getting around the fact that the article shows that (at least this version of) Linux doesn't integrate easily with Active Directory.

Also the author spends a quarter of the article explaining how to assign an IP address to an interface. If you haven't even got that far in your RHEL deployment, you're not ready to make the jump to AD authentication with custom Samba RPMs.

Five short paragraphs, of which the last two detail a non-standard step without which, according to the article, the whole thing would fail. Hopefully that'll save a few hours to someone trying to replicate this.

Authenticate Linux Clients with Active Directory (Technet)

jwb — Sun, 16 Nov 2008 18:59:53 +0000

The crack comes from building your own packages on RHEL5. The whole point of RHEL is you get support, but by building your own RPMs you become unsupportable. Also the author spends a quarter of the article explaining how to assign an IP address to an interface. If you haven't even got that far in your RHEL deployment, you're not ready to make the jump to AD authentication with custom Samba RPMs.

Authenticate Linux Clients with Active Directory (Technet)

eric_bursley — Sun, 16 Nov 2008 18:41:46 +0000

Obviously I missed that point, but if this functionality is suppose to be native to the RHEL distro, then there should be a bugzilla on it so that Red Hat can correct the problem.
My point here is that Red Hat supports only their binary built RPM's, and if someone wanted to use RHEL in a supported Active Directory configuration, they would need RHEL provided binaries.
Not trying to start a flame war here, just seeing a problem, and trying to get it corrected.

Authenticate Linux Clients with Active Directory (Technet)

dps — Sun, 16 Nov 2008 17:19:15 +0000

The article is not bad but anyone that *wants* to use SRV records better be very sure of their security. SRV records have two major problems:

1. They provide bad guys with a detailed guide to what services run on which hosts and the port numbers involved.
2. If an attacker can add a zone entry 99.98% of your authentication can be redirected to a box he controls. This is obviously undesirable.

AD almost *requires* that a DNS zone allows updates. This make problem 2 a good reason not to use AD if at all possible IMHO. I can see nothing AD does for which there is not a better un*x solution.

Centralised accounts can be done with NIS+, nfs and secure RPC.
SSO can be done using the s* commands and ssh identities.
Centralised configuration can be done using DHCP, tftp and nfs.
Failover and load balancing for services other than DNS and email can be done using multiple A records.

I would also note that the unix solutions also support enhanced access controls which do not exist on windows, period. A SELinux enabled desktop and some good application security policies would eliminate some classes of exploits that plague windows desktops.

Confined browser plugins is something I want. This could ensure that exploits, bad design of spyware features just result in "permission denied" :-)

Authenticate Linux Clients with Active Directory (Technet)

deleteme — Sun, 16 Nov 2008 12:57:38 +0000

As is stated in the article there are commercial options if you want to do this on Linux, so the easiest option would be to buy from them.

The problem was that RHEL doesn't include this. And I'm guessing they think there is too little market for it.

Authenticate Linux Clients with Active Directory (Technet)

gdt — Sun, 16 Nov 2008 07:54:23 +0000

Part of that sorry state is because Microsoft chose to "embrace and extend" Kerberos such that a typical Kerberos KDC was inadequate to authenticate both Windows and UNIX clients. It's this lack of willingness by Microsoft to "play nicely with others" that really annoys IT managers of large installations.

Authenticate Linux Clients with Active Directory (Technet)

jgg — Sun, 16 Nov 2008 07:15:00 +0000

Those are pretty good, here is a tip from my collection for your apache notes. Rather than use PAM, apache can use kerberos directly, this gives you single sign on for clients that support it and falls back to kerb based password authentication via auth:basic just like the PAM mode:

<Directory xxx/secure>
AuthType Kerberos
AuthName "Kerberos Login"
Krb5Keytab /etc/apache/apache.keytab
KrbAuthRealms REALM
Require valid-user
</Directory>

And then you have to generate SPNs for your server. This is the undocumented part.. Using samba to create the SPN keytab entries:

# net ads keytab add HTTP/foo.com@REALM HTTP/vhost.com@REALM [..]

Then split the HTTP entires out of /etc/krb5.keytab into /etc/apache/apache.keytab using ktutil.

Finally ensure your machine account in AD has the SPNs listed:
# ldapsearch sAMAccountName=web\$ servicePrincipalName
servicePrincipalName: HTTP/vhost.com
servicePrincipalName: HTTP/foo.com
servicePrincipalName: HOST/WEB
# kvno HTTP/foo.com
HTTP/foo.com@REALM: kvno = 2

Usually I use adsiedit on windows to set this, but any ldap client can do it if the user has privilege. I have yet to see a complete automated solution for this which is too bad since it is so close..

The registration of the vhosts is necessary for windows which does not generate the SPN in the same way as linux.

Enable network.negotiate-auth.trusted-uris in firefox to use kerb ticket passing.

The same approach works for creating any sort of SPN really..

Authenticate Linux Clients with Active Directory (Technet)

moreejt — Sun, 16 Nov 2008 04:25:28 +0000

This article is OK but leans toward FUD.

Maybe I didn't read slow enough but I didn't see valid justification for NOT using the built in samba and winbind in Redhat. My Redhat, CentOS, and Debian systems at work are fine with Active Directory. I use an Active Directory account on my Kubuntu workstation for daily work.

You might find my instructions a little more accurate and detailed
http://pcxperience.org/LinuxApacheActiveDirectory

Authenticate Linux Clients with Active Directory (Technet)

jgg — Sun, 16 Nov 2008 00:48:36 +0000

Having actually gone through this recently to setup Linux clients against an Active Directory server and tried all the options I can say the article is basically right that winbind is the best answer - that said, I don't use it yet at my shop because it has been too buggy in the 3.2 series.. Winbind has at least 4 key improvements against ldap or ldap+kerb
1) It is caching and uses AD caching hints to speed it up. 3.2 can even do off-line caching like windows for roaming users (!!!)
2) It mutually authenticates and encrypts all LDAP communication with kerberos without extra setup (MS's choices make it so that if you don't do this there is a raft of annoying configuration you have to do on the AD server)
3) It can detect and fail over (and back) to multiple AD servers
4) Password expiry, and forced change prior to logon works

Using Linux with an AD server is dead easy once you figure it out and provides real benefits to the Linux environment. If you have AD servers and are not using them as Kerberos servers with Linux you're really missing out...

The main sore point on the Linux side is that if you have Windows machines there is no free replacement for AD that is compatible with Windows clients and you pretty much have to have Windows Server to get the Windows clients working sanely. Samba 4 is the hope to fix this, but it seems far away still.

Unfortunately the samaba documentation is way out of date on how to do all this. Even if you don't want to use winbind, using 'net ads join|keytab' commands to manage the kerberos keys from ADS makes the client side pure kerberos setup dead easy. Modern MIT Kerberos even automatically uses SRV records and the like so configuration boils down to just setting the default realm.

Even the whole old problems with MS's Kerberos extensions seems completely put to rest these days. The kerberos libraries are now completely compatible by default and the Samba team has cracked the PAC and so on.

In the end the actual steps are pretty simple to get kerberdized ssh, apache, exim, dovecot and samba that fully interoperates for single sign on with windows clients and linux clients. But it was a total bitch to figure out due to the lack of up to date docs :( Particularly on the multi-homed SPN side...

Authenticate Linux Clients with Active Directory (Technet)

drag — Sat, 15 Nov 2008 21:52:28 +0000

Absolutely.

Getting a full Kerberos-based domain with proper authentication, proper network services, proper DNS support, proper LDAP authentication, and proper configuration management scheme is probably one of the most difficult and error-prone exercise that a Linux administrator is likely to desire to do

It's certainly possible. Most of the software that is required is provided by folks like Debian. It's not setup to do anything or actually work in any meaningful manner and there are gaps in functionality that a end user needs to work around.

Meanwhile Microsoft has provided it's enterprise customers these features, and more, with Active Directory in a relatively easy to use and effective package for, ohh, since Windows 2000 came out. Every version of 'Windows Pro' and 'Windows Server' is designed to work with Kerberos/LDAP/Configuration management/etc out of the box and in fact is harder to setup and manage without using Active Directory in many cases.

So Linux is about 8 years behind the curve here.

-------------------------------

To be brutally honest probably the best way to implement this sort of domain thing is to just run out to Best Buy and buy a copy of Microsoft Small Business Server and figure out how to get Samba/Winbind working with it. A LOT less headaches and a lot less error-prone.

This article is probably one the more useful bits of documentation you're likely to run across for most administrators trying out Linux. No joking.

------------------

Now, of course, with things like Samba4 and FreeIPA Linux may be starting to catch up, but it's worthless to end users until distributions realize the need and understand how to get something competitive to Active Directory/Small Business Server, up and running easily for end users.

This means secure LDAP, kerberos, proper network authentication, proper DNS, proper configuration management, proper configuration interfaces.. etc etc.

Then Linux on the desktop would probably start being taken more seriously by businesses. While the ability to have a spinning cube is interesting for end users the lack of the ability to manage users, their environments, and their passwords in a easy and secure manner is a big turn off for any IT person.

Fedora?

dwheeler — Sat, 15 Nov 2008 20:37:19 +0000

Fedora's installer lets you select how to authenticate your client, including Windows mechanisms. I haven't done it, so I don't know how easy it is, but it LOOKS easy from here.

Setting up an authentication SERVER requires more steps, but that's true for Windows too.

Authenticate Linux Clients with Active Directory (Technet)

jeleinweber — Sat, 15 Nov 2008 17:01:05 +0000

I personally find several advantages for using samba winbind over straight Kerberos + LDAP.

1. Samba joins AD as a regular host. If you want to use plain Kerberos with pam authentication, you'll have to make host/server@REALM users by hand in AD instead of machine accounts and export a /etc/krb5.keytab file using Microsoft's ktpass tool from the windows support tools. ktpass has a lot of weird limitations and an uncertain future. I have done this, and it works, but the samba way is easier.

2. Winbind can use regular microsoft groups. Most Unix -> LDAP solutions, regardless of what your LDAP server is (Microsoft? Sun? Novell? IBM? OpenLDAP), use rfc2307 attributes for uid, gid, home directory, shell, etc. There is a subtle but important difference between rfc2307 and rfc2307bis: group members in rfc2307 were LDAP IA5string types (lists of usernames, compare /etc/group). rfc2307bis also allows group members to be LDAP "distinguished names". Microsoft groups in AD use DN's in the "member" attribute. winbind lets you tap into the regular groups, including nested group memberships. If you don't use winbind you may be spending a lot of time mucking around in tools like adsiedit and using different procedures to edit your unix groups than your windows groups. Microsoft has extensions to their "active directory user and computer" tool for "unix attributes" tabs, but those don't include any decent editing support for group memberships. A plain LDAP implementation is going to have more trouble in /etc/nsswitch.conf with mapping groups.

3. Winbind will use the usual spnego encryption for its RPC calls, so you don't have to configure a certificate infrastructure to get LDAP over TLS. Unauthenticated users can't read the unix attributes, and you don't want LDAP clients binding to the server using plaintext passwords, so avoiding this makes life easier.

Note that you'd strongly prefer your windows domain controllers to be running at last server 2003 R2, as the microsoft's services for unix 3.5 on that platform will populate both the legacy microsoft msSFU30* LDAP attributes and the newer rfc2307bis attributes. In spite of the fact that the RFC status of rcd2307bis is "expired,experimental", it's the way of the future. Get a copy at www.padl.com; the main IETF repository purges the expired stuff.

Also, I'm liking "idmap ... = ad" for my winbind configuration, and recommend it to you.

Unfortunately, the documentation from the likes of Microsoft, Redhat, and Samba hasn't caught up with the software yet. Most of it is for samba 3.0.20 or earlier and windows server 2003. Lots of stuff you care about changed in server 2003 R2 and between samba 3.0.23 and 3.0.25, but the white papers and man pages don't reflect it yet. Sigh.

Authenticate Linux Clients with Active Directory (Technet)

lbt — Sat, 15 Nov 2008 15:52:12 +0000

> ldap - have fun setting it up;

FWIW I did setup a distributed pam/ldap authentication system at home for fun (and knowledge). If you have too much trouble with it then you're in the wrong job.

> the article claims you can't change passwords with it

The article doesn't say that, it says: "Furthermore, using the PAM LDAP module does not support changing reset or expired passwords."

Just changing passwords is fine - sorry, I don't run passwd expiry at home so can't easily verify that.

The article is good and well worth reading as *part* of your research if this area is of interest.

I would say that I don't know of any distro installers that ask about the "pam/ldap authentication server" and provide a manageable distributed multi-user setup out of the box. You know, the kind of thing that would be useful for keeping users on small LANs synchronised. Anyone?

Authenticate Linux Clients with Active Directory (Technet)

avik — Sat, 15 Nov 2008 15:23:23 +0000

My crack detector must be faulty. I didn't see any crack, only a reflection of the sorry state of Linux authentication.

nis - anyone can become any user using su. ldap - have fun setting it up; the article claims you can't change passwords with it; kerberos - impossible for a human to set up. Did I miss something?

Authenticate Linux Clients with Active Directory (Technet)

avik — Sat, 15 Nov 2008 15:10:35 +0000

If you continue reading the article, you encounter this:

Why did I download the Samba sources instead of a pre-compiled set of binaries? That was certainly what I attempted to do first. What I discovered after many hours with a debugger was that the binaries I downloaded were not built with the correct options to support Active Directory authentication. In particular, the code that supports Linux ID mapping in Active Directory was turned off in the default builds; hence I had to rebuild Samba with the appropriate build options. I'll talk more about ID mapping later in this article.

so it seems the issue really is complicated. Many will give up in disgust when things don't work as advertised; the author persevered, found out what's wrong and described how to fix it, only to be flamed on lwn.net.

Kerberos was an Industry Standard

macc — Sat, 15 Nov 2008 14:50:21 +0000

and Microsoft "improved" it towards incompatibility.

MACC

Authenticate Linux Clients with Active Directory (Technet)

macc — Sat, 15 Nov 2008 14:47:19 +0000

"Yellow Pages" is a lot older than that.

And (at least) the Motorola incarnation of SysV R3.*

had afair "rfs" per default( instead of nfs) allowing
networked device nodes.

macc

Authenticate Linux Clients with Active Directory (Technet)

eric_bursley — Sat, 15 Nov 2008 14:43:37 +0000

If you start reading the article, it actually says you need to download and compile Samba from source. If you are using a Linux distro like RHEL5 (which Microsoft demonstrates with in the article), you don't need to compile anything. In fact most distros have binary packages readily available. Again, Microsoft is over thinking the situation, making it seem more complicated than it is.

Authenticate Linux Clients with Active Directory (Technet)

clugstj — Sat, 15 Nov 2008 14:13:44 +0000

Windows was written with NO authentication mechanism in mind. It had to be bolted on when they wrote NT. Unix, on the other hand, has always had the concept of different users, so adding new methods of authentication was possible within the existing framework.

Authenticate Linux Clients with Active Directory (Technet)

k8to — Sat, 15 Nov 2008 02:39:55 +0000

Having experiemented with setting up kerb on my home network I can confirm. It's a pain.

Authenticate Linux Clients with Active Directory (Technet)

dcg — Sat, 15 Nov 2008 00:45:30 +0000

You don't need AD, but...for many people it's easier to use Samba (and hence, MS technologies) to setup linux networks than LDAP and kerberos. The fact is that Linux has never been very strong in that area.

Oh, and AD is more than authentication. XP client apps (like IE) obey the AD settings - that's something you can't do easily with Linux desktops right now.

AD is actually one of the reasons why people decides to use Windows Server and Windows Client in networks. Linux is really behind in this field.

Authenticate Linux Clients with Active Directory (Technet)

tzafrir — Fri, 14 Nov 2008 23:44:44 +0000

That "summary" paragraph is actually part of the introduction. The following paragraph begins with:

> The resulting plethora of authentication mechanisms was
> unmanageable. In 1995, Sun proposed a mechanism called
> Pluggable Authentication Modules (PAM).

That paragraph introduces PAM and NSS.

Authenticate Linux Clients with Active Directory (Technet)

raven667 — Fri, 14 Nov 2008 23:38:21 +0000

I am confused as to why I need to use samba and winbind rather than just Kerberos and LDAP
directly, presuming I'm willing to give all my LDAP user accounts UID/GID and home directory
attributes. An article on how to do AD user/group info using just LDAP would be nice.

Authenticate Linux Clients with Active Directory (Technet)

allesfresser — Fri, 14 Nov 2008 23:33:13 +0000

Could you detail the general gist of the aforementioned crack smoking for those of us who don't regularly deal with Samba configuration or AD? I fully believe your assertion, but am missing the details because of unfamiliarity with the particulars.

Authenticate Linux Clients with Active Directory (Technet)

jwb — Fri, 14 Nov 2008 23:28:59 +0000

You have to go to microsoft.com to get that much crack smoking in one article. I look forward to future insane articles from this same source.