Samba with Active Directory: getting bigger?
Posted Feb 4, 2010 12:34 UTC (Thu) by buchanmilne
In reply to: Samba with Active Directory: getting bigger?
Parent article: Samba with Active Directory: getting closer
Samba relies on NTLM for authentication.
That is not entirely true. A Samba3 domain controller only supports NTLM,
and Windows clients will not do Kerberos authentication without an AD-
compatible KDC/directory. However, Samba3 "client-side" features support
Kerberos, and (AFAIR) Samba3 clients can use Kerberos authentication to
However, in an AD environment, I still have NTLM/MSCHAPv2 around, for EAP-
PEAP/TTLS (the only two password-based secure authentication mechanisms for
WPA2-Enterprise). A GSSAPI authenticator for EAP would help AD and non-AD
environments (and bring "Single Sign On" EAP to Unix).
After putting weeks of effort into figuring out to use
and use TLS with OpenLDAP and Kerberosv4 on Debian and actually using that
sort of domain at home for months and running into issues and bugs and
other such things.. I could not be depended on successfully run a KRB/LDAP-
based domain using Linux and OSS tools.
This is simply due to a lack of standard tools for provisioning the
directory and automating configuration. Samba's support for AD replication
etc. is orthogonal to this (however the setup/provision scripts shipped
with samba4 do this). Some Linux server-oriented distributions (e.g.
Mandriva MES 5) do provide GUI tools for provisioning the OpenLDAP/Samba3
side (and the Heimdal bit can be added quite easily, but will require some
file editing and commandline operations).
Even without a GUI tool like this, you can quite easily set this up in a
few hours (with Heimdal, or quite recent MIT Kerberos, Kerberos principals
can be stored in-directory as well).
If you want a simple example of how AD features can improve
security of running Linux look no further then OpenSSH.
None of these benefits are AD-specific, and many environments have been
running Kerberos for these features for years.
Single Sign On and with a bunch of Web services, Email, Groupware, and even
a very large amount of open source software.
But, you can do this all with plain Kerberos (Firefox, Apache and Squid can
give you single sign on for web and proxy, Dovecot and KMail can give you
IMAP with GSSAPI). The problem though is that many other networked
applications could benefit from Kerberos/GSSAPI, and with AD or
MIT/Heimdal, you will still not have Single Sign On for everything.
When Samba4 AD stuff reaches prime-time and IF distros pick
up and run with it then it should make it massively easier to do all sorts
of things that would not make deploying Linux systems and Linux-based
services cheaper, but also massively more secure.
You're assuming that the Samba4 AD server-side implementation will
magically provide "client-side" policy application for Linux (e.g. firewall
rules or VPN policy deployment on Linux servers in a Samba4-based AD
domain)? No, Samba4 will only make deploying linux systems to provide
Windows-based services cheaper.
It should be as easy as a admin logging in locally to a Ubuntu or Fedora
machine and choose 'join domain' during installation, provide a admin
domain password, and then *poof* your done.
This is already available in most distros (supporting both traditional
LDAP/Kerberos and AD), and doesn't require any Samba AD server-side
Make it easy to lock down the desktop.. deny access to flash
drives if you want or not. All sorts of stuff that right now is very
tedious to do.
Uh, Samba4 won't do anything like this for you ...
Mandriva had a feature (in Corporate Desktop 4 I think) allowing KDE
configuration deployment in LDAP, and this was supposed to be merged into
KDE 4.4 (it's probably been deferred again), but currently none of the
desktop configuration technologies have any support for remote policies.
However, what I am concerned about is that, while there has been no
obstacle to doing this kind of thing for Unix-based deployments
(LDAP+Kerberos), suddenly people will look at doing it the MS way (which,
again, they could have done before, without Samba4), locking Unix into
requiring MS technologies, when Unix technologies could have been used from
For example, are we expecting Windows GPOs (which are pointers to Class
IDs, which are then registry files retrieved via CIFS/SMB from the SYSVOL
share on a DC) to be supported by Linux desktops? Effectively requiring a
Windows-compatible registry implementation (and possibly translation of
various Windows-based concepts/names/conventions to Unix ones, including
paths, application named etc.)?
IMHO, the desktop environments should have been considering these kinds of
features already, and they could have been implemented before, supporting
both straight LDAP and AD, with AD plugins (allowing administration of
"Linux" GPOs with Windows-based AD administration tools), without having to
wait for Samba4.
to post comments)