Samba with Active Directory: getting bigger?
Posted Feb 4, 2010 22:07 UTC (Thu) by buchanmilne
In reply to: Samba with Active Directory: getting bigger?
Parent article: Samba with Active Directory: getting closer
Policykit is designed allow policies to be distributed when
comes to system permissions.
That's a bit optimistic isn't it? Posts on
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
XML method, but can be configured to use LDAP backend.
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
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
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
nsswitch and other things can cause really huge headaches
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
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
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
do you know the best way there is to deploy a directory
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
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-
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
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.
to post comments)