Samba with Active Directory: getting bigger? [LWN.net]

Samba with Active Directory: getting bigger?

Posted Feb 4, 2010 22:07 UTC (Thu) by buchanmilne (guest, #42315)
In reply to: Samba with Active Directory: getting bigger? by drag
Parent article: Samba with Active Directory: getting closer

Policykit is designed allow policies to be distributed when it comes to system permissions.

That's a bit optimistic isn't it? Posts on the development list from two weeks ago show that the work to allow this to be developed isn't shipping in a released version of policykit yet, let alone in a distribution.

These all use Gconf, which by default uses the directory tree + XML method, but can be configured to use LDAP backend.

I can show you how to use AD to deploy those things. It is certainly much easier then trying to do it with a pure OSS solution.

Please do (although, documentation should be sufficient, it has been for me for OpenLDAP, Heimdal, nss_ldap, pam_ldap, samba, sudo etc. etc.). Difficulty depends on many factors, for me it would probably take less time on a pure OSS solution than trying to arrange a Windows server license from the windows guys ...

OpenLDAP is a pain to work with

No more so than samba or Apache or bind or ISC dhcpd or many other server- side tools (IMHO). OpenLDAP can be configured over the wire (which Apache, bind and dhcpd can't, except for dhcpd with the LDAP patch and OpenLDAP). ISC dhcpd can't even tell you how many leases are free (I guess if you know the ranges, e.g. from an LDAP search for a server with LDAP configuration, you could query all the IPs via OMAPI), you would have to parse it's lease file! This is really a case of no-one being interested in writing good deployment/mangement tools, rather than problems in OpenLDAP itself.

nsswitch and other things can cause really huge headaches and even booting problems unless you configure them exactly right.

nsswitch is going to come into the picture with any non-local user store. If you mean nss_ldap, then yes, maybe the upstream defaults are wrong (and some distros patch those defaults to avoid this problem). Of course there is an alternative to nss_ldap (nss_ldapd) which don't have these problems. And, BTW, this is a relatively recent problem (since nss_ldap 239 or so, years of nss_ldap use before 239 didn't have this problem).

PAM is regularly abused by people deploying LDAP and Kerberos and is used improperly.

Uh, well, something has to get the initial TGT, it might as well be PAM. For applications that don't support SASL or GSSAPI, there aren't any better options (which gets us back to the fact that more apps should have GSSAPI support, for both AD and non-AD).

You still have to integrate PKI support and properly securing access to LDAP with TLS is a whole hell in itself.

But, again, PKI improvements are useful in other areas, and they could have been done with or without Samba4. While Red Hat now provides us with an open-source CA (ugh, Java), and other solutions (such as OpenCA) have been available for actually managing certificates (and support clients - such as Cisco VPN routers - doing automatic enrolment, e.g. OpenCA with SCEP support), again it is the client-side aspect that is quite limited. For example, certificate enrolment support (e.g. SCEP, not to mention anything newer) support isn't available in any open-source SSL client applications (e.g. openvpn, WiFi clients for WPA2-EAP-TLS), and command-line SCEP applications (e.g. autosscep, sscep etc.) are not that mature and not widely deployed, not to mention not integrated.

In my experience, most semi-competent AD admins don't get PKI right on their own anyway, so I think this is a moot point.

(In fact, on #ldap and #openldap, most certificate problems are/were related to Debian's incomplete/premature GnuTLS port, prior to 2.4.17 when Howard fixed a lot of problems, some of which required fixes to major problems in GnuTLS)

What are you going to do when 'Human Resource' folks, who barely know the difference between a monitor and their computer, are going to have to make name badges and add users to your OpenLDAP system? Give them a bash script?

In the company I am at at present, HR sends a mail to the Windows admins, who create accounts in AD. In non-AD environments I have made web interfaces available, or (if samba is a requirement) made User Manager for Domains available.

do you know the best way there is to deploy a directory system for Linux?

It may be the quickest, but whether it is the best would depend on real- world requirements. In a number of real-world situations, I have found a 30-minute Samba+LDAP+Heimdal setup to be a better solution. BTW, with AD and Linux clients, you don't need any Samba bits unless you need to serve something to windows clients, nss_ldap and pam_krb5 are enough.

And AD is lightyears ahead of what is available from a pure OSS solution based on Linux _right_now_.

But, 90% of that is Windows integration into AD, not AD itself. The other 10% is what the Samba guys have mostly got working with current Samba4.

Even if 80-95% of the PCs in a organization are running Linux your still going to need Windows integration support.

Not necessarily, the rest could be Macs :-). But if I have a Samba4 installation backed on OpenLDAP, does any client side integration *have* to require CIFS for policies, Windows RPC services and various other bits and pieces just because people implemented the client side integration the way Windows did it? That would only be useful if the client side implementations are compatible enough (requiring translation of registry keys to GConf keys etc.), and doing it in such a way that the Windows protocols aren't required would leave the door open for people to have non- Windows environments.

So Samba is going to get used one way or another. With Samba4 we have a real opportunity to make these things easy to deal with allow a pure OSS/Linux based solution to seriously start displacing Windows server systems in many organizations.

Of course samba is going to be used (and has been even before it got AD support, even as a domain controller). However, my point is that it should technically be possible to have the features without AD-compatible support in Samba, which would actually pave the way for having them AD-compatible sooner.

Too much focus is given on "We need an AD-compatible server", and too little on "We need to ensure that we provide means of lowering the cost of configuration, allow less costly implementation of controls", deferring until the gaps are so obvious because a Samba4 deployment with Linux desktops doesn't do what people had hoped.

I still run into technical people who think that AD controls computers, rather that the OS having support for the controls that AD provides. For example, I have seen companies where internet access is controlled by a GPO which sets the proxy settings. This is bypassed by many staff by simply running a different browser (e.g. Portable Firefox) and setting the proxy settings correctly). If people think Samba4 will magically make Linux desktops adhere to GPOs, then they are going to be in for disappointment.

The other concern is that focusing on Samba4 may worsen the situation where people rely on Windows-based technologies unnecessarily, such as many cases I have seen where people struggle to set up CUPS to Samba to CUPS printing, when CUPS to CUPS works with so little effort.

Samba4 isn't the silver bullet for suddenly making Linux desktops enterprise-ready, and it seems some people think it is.

In short, I don't see why we need to throw away a Linux server and client option just to displace more Windows servers. Linux desktop use is growing as-is, there are many people running environments with OpenLDAP+Samba3 (just hang out on #samba or #openldap or #ldap), many with a few Linux desktops. Having working solutions for them now would probably accelerate adoption when they can show others how easy it is once Samba4 can satisfy more people's requirements.

(Log in to post comments)

Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 15:04 UTC (Fri) by drag (subscriber, #31333) [Link]

PAM is not networkable. Your application needs to natively support Krb5 through GSSAPI or whatever to actually be useful in a networked domain environment.

Its pretty easy to understand why PAM sucks when you look at using it with telnet or ftp versus native kerberos support. As a part of the old normal Kerberos way of doing things kerberized versions of ftp, telnet and a couple other things were commonly supplied with it.

So if your using PAM + ftp then this is how things work:
* User logs in to their local computer. This works through a series of encrypted packets with the various krb services. They cache their credentials locally and they will be valid up to 8 hours or so (configurable)
* User runs the ftp client program to log into a remote ftp server.
* The user gets prompted for their username and password.
* the user supplies username and password.
* The server then uses PAM to do look-ups and effectively does a local login for that user.
* The user is granted access to the ftp server.

IF your using a ftp server with native Kerberos integration then:
* User logs in to their host, gets the credentials; caches them.
* User runs the ftp client program to log into the remote ftp server.
* User gets requests a ticket from the krb ticket granting service to get to the ftp server. Ftp server also supplies it's credentials as part of the kerberos protocol.
* User is granted access to the ftp server.

So you see with PAM + ftp the username and password are transmitted in plain text over the network. There is no proof that the server is the correct one either. You could be logging into one via DNS poisoning attack or some other thing. This makes it trivial for the attacker to gain access to your user's account. With SSO schemes and kerberos this makes the problem especially critical since you will be using the same username and password for _everything_.

However with the correct kerberos integration you have no password being transmitted over the network... in plain text or encryption. The protocol eliminates the need to ever transmit passwords over a network (except for the user to change a password or during the initial user setup). Also the ftp server identity itself is also confirmed. As part of the kerberos protocol each server itself has to be added to the domain and it has it's own credentials that get used as part of the authentication stuff. (of course ftp being plain text means that its trivial to intercept traffic after the fact, but whatever)

With properly encrypted services, like OpenSSH, it is more of a toss up whether you want to use Openssh's password challenge-response support or use it's native kerberos support. There is some flexibility lost in using full kerberos setup and it's ok to transmit passwords over the network as long as they are properly encrypted. However generally its probably a good thing to use native kerberos when its available. You can use kerberos to eliminate the possibility of brute force password attacks on your SSH server (although it does not prevent users from trying brute force by logging into the domain) and it can get rid of the need for OpenSSH's private/public keys which is inherently very difficult for administrators to properly manage and does not scale well. (as illustrated by successful malicious attacks the Debian and Fedora folks suffered in the past)

Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 15:05 UTC (Fri) by drag (subscriber, #31333) [Link]

Oh. And that is not to say that PAM is not useful for local logins. Thats
fine. Its just when you use it with a networked service is when it is a bad
thing.

Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 15:40 UTC (Fri) by drag (subscriber, #31333) [Link]

Since it only considered GConf-based applications, and was started after the projects (shipping KDE only) for which I had time to look at some of these issues, I haven't investigated sabayon much, but documentation on LDAP support in Sabayon is by no means easy to find. Old links no longer work, and searches don't return any relevant results. Very little documentation is shipped with the packages, and I see no obvious way to do this in the sabayon admin GUI.

Yeah. Your right on both the Gconf accounts. My bad. Sayabon is useful for building gconf configurations. You still need some way to deliver them.

I knew that Likewise's commercial product supported using AD to integrate Gnome support. I thought it used a gconf backend, but actually it just turns out to be backed by the use of generated zip files to deliver configurations.

lease do (although, documentation should be sufficient, it has been for me for OpenLDAP, Heimdal, nss_ldap, pam_ldap, samba, sudo etc. etc.). Difficulty depends on many factors, for me it would probably take less time on a pure OSS solution than trying to arrange a Windows server license from the windows guys ...

Dude. Setting up a domain using Samba 4 involves a single command line (after it has been installed). For setting up a SBS requires even less effort then that. The basic functionality for most of this stuff has been around for nearly 20 years. It should be there by default.

And I know for a fact that setting up a active directory system, even with licensing, will be dramatically cheaper then trying to train a bunch of admins to create their own LDAP schema...

In the company I am at at present, HR sends a mail to the Windows admins, who create accounts in AD. In non-AD environments I have made web interfaces available, or (if samba is a requirement) made User Manager for Domains available.

Yes _you_made_it_yourself_. Right. How much does your salary cost? How much time did it take for you to set it up and get it working? How much training did you have to do and how many times did it take for people running into problems with your web interface before you got all the bugs worked out? In terms of dollars try to guestimate how much time and money was spent on that.

Yes it is very possible for people to use OSS solution to setup a Kerberos and LDAP domain for a large business. Its going to take a lot of time and it is going to be very expensive for them to do this.

And you STILL will need a Active Directory server for Windows support

Go and look at a average small or medium business (which is the VAST majority of people. Large corps only employee a minority number of people compared to small/medium enterprises) with 50-500 employees or so. People that cannot afford a full time IT staff or anything of that nature. Their IT person is probably on the level of "some guy that built his own computer". They rely on external support and buying out of the box solutions. They can have the choice of hundreds of Microsoft certified folks that can come in and bang out a AD solution for them in a matter of a couple hours.

Now tell me how well a OSS solution is going to work out for them. (and don't try to tell me that AD is overkill and they should not be using a domain. Small/Medium business still need proper ways to manage resources and security is still important. Also OSS is competing with a established player here and not on equal ground.)

Too much focus is given on "We need an AD-compatible server", and too little on "We need to ensure that we provide means of lowering the cost of configuration, allow less costly implementation of controls", deferring until the gaps are so obvious because a Samba4 deployment with Linux desktops doesn't do what people had hoped.

Right. Active Directory includes the administrative tools as well as the Windows RFC support and other things necessary to manipulate the Windows registry and various scripts integrated into Windows by default to get (very important things)

So yes the AD requires integration on the client side. This is true for Linux. I hinted at this in my other posts by saying you need to have distros with proper integration. I should have emphasized this point more.

The support for integration into a proper domain must be improved on the distro-side. Even with Samba4 making it trivial to create a domain system it still requires more client side configurations to make it work and that should be trivial for end users to accomplish also. Unless that happens then the whole thing is mute.

The other concern is that focusing on Samba4 may worsen the situation where people rely on Windows-based technologies unnecessarily, such as many cases I have seen where people struggle to set up CUPS to Samba to CUPS printing, when CUPS to CUPS works with so little effort.

For XP, at least, IPP support sucks. (this hopefully improved with Vista and Windows 7) So you will still need Samba printing support for Windows clients for the most part. Especially seeing how many businesses try to control costs by monitoring who uses what printer.

But your right that in many cases if your just using Linux/OS X clients then going from CUPS to CUPS is much easier then going from CUPS to Samba+CUPS. Unfortunately that does not eliminate the need for people to configure Samba to work with a CUPS server for most people, unless they go with a fully networked printer (which is likely running Samba anyways... ;) )

Use-Prevention Technology (slightly Off-Topic)

Posted Feb 12, 2010 19:02 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

the truth is that an Enterprise network is not a free-for-all with everyone running whatever they want and doing whatever they want.

you have a small (compared to the userbase) team of admins who are managing lots of machines. They need to the machines to continue to match what they expect them to be running. A significant part of this is preventing people from installing/doing things on those machines that they are not supposed to (another part is publishing the correct software and configs out to the machines, but this currently has many solutions)

these machines are company machines, supporting the business of the company. They are not the users personal machines.

in the old days there was the central mainframe and everything had to go through the admins, then with the PC the processing power (and administration) got distributed. What companies are finding is that this has some fairly significant problems.

Among them is the fact that since the company owns the computers, the company is liable if any illegal, the company needs to control what gets installed on the machines.

Another issue in many environments is that the company is liable for damages if the wrong data leaves the company. This can't be completely prevented, but it can be made difficult enough that it won't be done accidently.

Now I would be the last to try and claim that there aren't companies who just have bad management and who micro-manage their employees just because they can, but there are real needs for theseuse-prevention technologies. The uses are almost all int the enterprise, and at this point this space is one of the few areas where a lot of work is needed (I don't count reverse engineering the exchange protocol to be in the same class, while that's very important to users (myself included), it's not a requirement for any enterprise that's willing to break the exchange shackle, and there are a lot of options there)