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 Samba3 servers.
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 OpenSSL 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 the 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 it 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 features.
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 the start.
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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds