Samba with Active Directory: getting closer [LWN.net]

February 3, 2010

This article was contributed by Don Marti

From one point of view, Samba is open source high drama at its finest: an early adopter of version 3 of the GNU General Public License, and the recipient of an unprecedented release of formerly proprietary Microsoft documentation, thanks to a high-profile anti-trust case. Meanwhile, though, it's the low-profile software that implements the Server Message Block (SMB) file-sharing protocol, sometimes known as CIFS. Samba powers every inexpensive NAS device in the computer store—without even a mention on the box—and comes with all the common Linux distributions and with Apple's Mac OS X Server. Today, as Samba comes closer to implementing a key Microsoft directory protocol, the two aspects are being forced together.

Samba creator Andrew Tridgell, better known as Tridge, posted to his blog, "There has been a lot of progress recently in the development of the directory server capabilities of Samba4." In a half-hour screencast video, he demonstrated a development version of Samba acting as a Microsoft Active Directory domain controller in a mixed environment. "We are making very rapid progress now," he added.

Active Directory (AD) is a central repository for all the administrative information that a modern Microsoft Windows site needs. Besides user names and passwords, AD functions as a DNS server, stores network configuration policy such as firewall rules, and acts as a back-end for applications' configuration. Microsoft Exchange, for example, is completely dependent on it.

AD is made up of "domains" which are data structures that contain groups of objects, which might represent everything from an individual printer to the entire company sales force. Domains can then be collected up into "forests". A company might have many AD domains within its forest, and everything in the forest can be managed by the same administrators. Because AD is such a critical service, Windows sites typically install multiple AD servers, which replicate their data using a formerly secret protocol.

The Samba team received Active Directory documentation, including the server-to-server protocol, as part of an agreement made in response to a European Commission antitrust case in 2007. The documents have helped the project, Tridge said:

Stefan Metzmacher had managed to decode some very important parts of the protocol as part of his thesis work, but we were still missing some key parts of the puzzle. The documentation from Microsoft filled in many of these key elements, and perhaps more importantly, Microsoft has been very willing to engage with us to fill in any gaps that we find, including working directly with traces of Samba talking to Windows domain controllers to enable us to debug our implementation.

The documentation project was a huge project from the Microsoft side. Tridge described it this way:

I think it is fair to say that the WSPP/MCPP documentation effort is one of the largest efforts in IT history to document a set of network protocols. The sheer scale of the effort means that there are inevitably errors and omissions. We have been pleased at how Microsoft has responded to our reports of these errors by providing us with additional documentation where needed.

In the video, Tridge demonstrates provisioning an Active Directory domain on a Samba server, running a development version of Samba from shortly before Samba 4 alpha 11. Once the Samba server is running, he then starts a copy of Microsoft Windows Server 2008R2 Standard as a guest under VirtualBox, and runs the Windows "dcpromo" command to have it join the domain as a domain controller.

A few clicks and entries in the "Active Directory Domain Services Installation Wizard" later, the Windows box is ready to reboot and come up as part of the domain originally created on Samba. It takes about 30 seconds to synchronize key information for the newly-created domain. This step might take hours on a larger, longer-running domain.

Samba 4 has a few limitations, compared to a Windows AD server. There is only one domain per forest, and only one site per domain, but Tridge says that removing those limitations are near-future priority tasks. Windows administrators, like sysadmins everywhere, fall all over the "lumpers" vs. "splitters" spectrum, and anyone but extreme lumpers with simple configurations will need the ability to define separate domains, for departments and roles, and separate sites, for physical locations.

The remaining manual step is to add the Windows domain controller to the DNS zonefile on the DNS server. Microsoft's Active Directory handles DNS duties itself, while Samba relies on the system nameserver. A change to a Samba AD domain requires a corresponding change to a zonefile on the nameserver. "What we don't yet support in Samba 4 is the ability to create arbitrary DNS names within a Bind9 server using Kerberos authenticated DNS requests," he said. "Microsoft stores DNS within Active Directory. We can't join a Windows domain controller as a new DNS server, so have to rely on the Unix machines to provide DNS," he added. After recording the screencast, Tridge did write a script to automate the needed zonefile changes, he said.

Tridge's screencast shows the Windows box successfully syncing with the Samba server, and a user added on the Windows side shows up quickly in a search of the Samba server. Samba 4 is also able to join an existing AD domain. A tool called "vampire" is the Samba-side equivalent of the "dcpromo" command on Windows. Tridge demonstrated using it to add a second Samba server to the domain, ending up with a domain with two Samba servers and one Windows server. This ability means that an administrator could soon add a Samba appliance to an existing AD network, reducing the number of actual Windows servers needed.

Integration and the "Franky" concept

Samba 4 is an ambitious rewrite, which has been in progress since 2003. Meanwhile, Samba 3 has been through many releases with incremental improvements, and currently works well as a member, but not a domain controller, of an Active Directory domain. Samba 3 is "closer and closer to Windows compatibility in timestamps and Windows ACLs. It's harder and harder to tell us from a Windows box," Samba team member Jeremy Allison said. Thanks to extensive usage and bug reports, Samba 3 has gained the ability to handle real-world client quirks, while Samba 4 has focused on the big AD problem but not faced the day-to-day beatings of production use.

Tridge said that in addition to remaining AD work, "we also need to find out exactly how we will achieve our stated goal of re-integrating the great file sharing and printing work that has been done in the Samba3 branch with all of the work on Active Directory server support in Samba4."

Samba developers have been discussing ideas for combining the new functionality in Samba 4 with the existing Samba 3 code. One design for a combined project, called "Franky," short for "Frankenstein," would run Samba 3, listening on the SMB ports (139 and 445), along with Samba 4 listening on the ports required for AD support. Another alternative would be to run Samba3, but pass through AD-related requests to Samba4. "Obviously this will require quite a lot of merge work, but we believe this may be possible to achieve in 2010," Jeremy said on the Samba team blog.

Tridge said:

We need to have a single common file server component and printing component again. The strain on the team of having two implementations of the file serving component is too great. One way of achieving that is via something like the 'Franky' approach, but that has a significant downside of making deployment and administration of Samba more difficult. We need to put more thought into how we can make it easy for administrators, while also offering the best set of features from both branches.

"I'm expecting a fairly heated discussion at SambaXP this year," said John Terpstra, Samba team member and chief software architect of ClearCenter, which produces a web-administered distribution for small and medium businesses. The SambaXP conference is scheduled for May 3rd - 7th, 2010 in Göttingen, Germany.

Licensing and downstream

Samba with Active Directory is still not on downstream roadmaps. Simo Sorce, Principal Software Engineer at Red Hat, who maintains Samba packages for Fedora, said that project is looking at including Samba 3.5.0 in Fedora 13, if it's ready in time. But AD is still in the future. For future releases, "We will wait until the solution is stable enough that upgrades won't mean your server has a good chance of breaking," he said.

ClearCenter's ClearOS combines network gateway with VPN, web and mail filtering, Samba file server, Kolab groupware, and web-based administration tools into a package designed for resellers to deploy at small businesses and branch offices. Samba is a key part of the company's product, which competes with Microsoft Small Business Server but with a monthly subscription bill instead of an up-front license price. ClearOS is based on CentOS, a rebuild of Red Hat Enterprise Linux, but includes Samba 3.4 in place of CentOS's 3.0 package. "ClearOS 6 is going to ship pretty quickly after Samba 4 ships," John said.

Samba adopted version 3 of the GPL in 2007. One effect of the new license was to prohibit downstream Samba resellers from entering into new patent license agreements covering Samba, like the controversial Novell-Microsoft patent deal of 2006. Samba's license change doesn't affect Novell, whose contract predates the GPLv3 cutoff date, but according to the Samba web site, "Patent covenant deals done after 28 March 2007 are explicitly incompatible with the license if they are 'discriminatory' under section 11 of the GPLv3."

No GPLv2 fork has emerged, and, Jeremy says, the license change "has essentially been a complete non-issue." Downstream vendors ship Samba on everything from tiny NAS devices that connect to a USB drive, up to IBM's Scale Out File Services, which runs clustered Samba on top of IBM's proprietary General Parallel File System (GPFS). "What Samba does is it turns the CIFS server into a commodity, allowing people to compete on back-end scaled clustered filesystems," Jeremy said.

All of the Samba code is under individual copyrights, without assignment. "It's completely impossible to be bought out," Jeremy said. "No one can get any advantage over anyone else in the Samba code." As part of the agreement with Microsoft, the company must disclose any of its patents that it believes are necessary to implement its protocols, and it has not added any to its list since reaching the agreement. Microsoft has been "very cautions about breaking compatibility," Jeremy said. "With Windows 7, Microsoft made sure that it would work with a Samba 3 domain controller." Microsoft ended support for Windows NT 4, the last of its OS products to implement the old NT Directory Services system, at the end of 2004, and Windows 7 does not work with an NT4 domain controller, he added.

Help wanted

As you might expect, the Samba team is looking for help. Tridge invites new contributors: "Join the #samba-technical IRC channel (on the FreeNode network, irc.freenode.net), join the samba-technical mailing list, and get involved with the development process. Point out what the priorities are for Samba4 before you would consider deploying it, and help us to prioritize our development to meet your needs."

Jeremy asks would-be redistributors and SMB appliance vendors to work on functionality they anticipate needing. "If you're planning on a product within the next 18 months, the earlier you get involved the more chance you get to steer it to do the things you need to do," he said. "If you need Samba to interface with a particular filesystem, give us a VFS module that will let us do that," Jeremy said. Contributions to Samba itself have to be licensed under the GPLv3, but the team does want to be able to run Samba on the user's choice of clustered filesystem.

Then, as Jeremy posted, "Once we have a merged code-base, we'll declare victory, ship Samba4 and have the biggest darn release party since Duke Nukem Forever shipped and revolutionized computer gaming ! :-)." Samba 3 has served well as an essential file server, and Samba 4 has broken new ground in Microsoft protocol discovery, but eventually, one way or another, there will be one Samba again.

(Log in to post comments)

Samba with Active Directory: getting bigger?

Posted Feb 4, 2010 11:04 UTC (Thu) by drag (subscriber, #31333) [Link]

Yeah. Find a corporate building and shift through the trash. You'll be able to find a machine with 50x more resources that people regularly throw away. If that is not appealing then just buy a SheevaPlug for less then 100 bucks and get a 1ghz cpu and 512MB of RAM.

Active Directory itself has massive amounts of important functionality that makes is far superior solution then what Samba 3.x can offer, even for simple file server solutions. It makes spending a trivial amount of cash completely worth while.

I mean you can't really even find Windows 2003 or 2008 server floating around that is not using AD in some fashion, unless it was set up by a non- technical person. The advantages of having a integrated and easy to deploy system that you can hook many other services up to at a later date is just insurmountable. If you have a windows admin and they are NOT using, at minimum, Small Business Server when deploying a bunch of Windows system.. even for a simple file server.. then they have no business working as a admin.

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

Here is a easy example:

Care about Security?

Samba relies on NTLM for authentication.

NTML v1 and v2 rely on MS-CHAP (v1 and v2) to do the network stuff. Which means that for network security you are depending on DES encrypted MD5 hashes; which we now is increasingly worthless when it comes to security.

And what is even worse is that unless you specifically specify things in the Samba config your server will accept plain text passwords. Which is something even that Microsoft Windows does not even support anymore.

Even not considering that DES and MD5 stuff is weak, the actual MS-CHAP and NTLM protocols themselves has many known weaknesses and vulnerability. This is compared to Active Directory that uses Kerberos, which is a well know, very widely used, and very secure protocol. Why do you suppose people recommend not using PPTP, for example? Because the authentication stuff is weak and it is the same stuff that Samba 3.x depends entirely on.

So if I was a IT network security guru type person and I held network security as the highest requirement then there would be no way I could allow any Samba server to exist on my network, nor could I allow any Linux desktop to exist in a Windows environment.

Despite the fact that people here will (quite correctly) will scoff at the poor quality of Windows host-based security.. Microsoft's AD network security far surpasses anything that is _reasonable_ to deploy using Linux systems. Sure if you have people that are highly knowledgeable Linux folks working in a professional environment can deploy a very secure network setup with available tools, I don't see how anybody can reasonably do it for Linux desktops for any sort of small or medium enterprise.

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. Even with a full month of effort the best I could do would be to get to work well... I still would not be comfortable with it without having to have a third party come in and audit my setup. Meanwhile a A+ network cert with barely enough knowledge to pop a CDROM into a PC can deploy a SBS setup with far superior results in less then a day of effort.

A experienced Windows admin can then come in and lock down things quite a bit by a few group policies. Eliminating old vulnerabilities kept around due to requirements for backwards compatibility. Things associated with password caching and all that. Be able to use modern and secure protocols like IPSEC to do tunneling and get all sorts of nice integration with Single Sign On and with a bunch of Web services, Email, Groupware, and even a very large amount of open source software. Eliminating a whole host of security issues associated with having to send passwords over HTTP or IMAP or SMNP and all that.

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

If you want a simple example of how AD features can improve the security of running Linux look no further then OpenSSH.

No more having to have shared keys. No more 3DES encrypted files that will give unfettered access to all your servers.

Servers and Clients have to have proper credentials. Pretty much complete and total elimination of any sort of possibility for a Man-in-the-middle attack. No having to guess that server you just logged into for the first time is the right one (How many times have you wrote down your server's ssh fingerprints so you can compare them with what shows up the first time you log into it?). Unless the server you ssh'ng into has proper kerberos credentials then they cannot even pretend that they accept your user's credentials.

You can disable password support altogether and eliminate the ability for people to try to brute force your OpenSSH servers fishing for weak passwords.

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

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.

Think about all the effort of having to setup MIT Kerberos + OpenSSL + OpenLDAP + GSSAPI + whatever on a Ubuntu system and having to go through large amounts tedious and error prone configurations versus being able to walk down to a store and spend a 150 dollars on a NAS device with Samba AD integration in it. It would do to the server market what the netbook did to the laptop market and if distros do a good job of integrating Samba4 features then it can make deploying Linux desktops in a small or medium business very close to being trivial.

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. Users are automatically able to use the machine, the machine automatically is able to use any services on the network in SSO fashion. DNS names are automatically setup and configured correctly. 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.

Samba with Active Directory: getting bigger?

Posted Feb 4, 2010 12:34 UTC (Thu) by buchanmilne (guest, #42315) [Link]

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.

Samba with Active Directory: getting bigger?

Posted Feb 4, 2010 17:10 UTC (Thu) by drag (subscriber, #31333) [Link]

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.
 
Yeah they do.

Policykit is designed allow policies to be distributed when it comes to
system permissions. Whether or not users are allowed to update or install
software, mount drives, configure network, etc etc.

Then for the Gnome desktop you have Sabayon for building profiles (default
apps, configurations, etc) and Pessulus for providing lock-down policies
for the Gnome desktop. 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.

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),

Yes there is. There are huge obstacles to this, like I said in my previous
post. Almost nobody does it properly out of the box. Redhat comes closest
and they have their Identity management packages and other related items,
but that currently mostly for people that need to migrate away from NIS for
regulatory reasons. (and most of those people will just migrate from NIS to
AD for obvious sanity reasons)
 
Mandriva MDS seems 'OK' also, but almost nobody uses Mandriva anymore.
 
There are dozens of configuration changes you have to make. OpenLDAP is a
pain to work with, and nsswitch and other things can cause really huge
headaches and even booting problems unless you configure them exactly
right. PAM is regularly abused by people deploying LDAP and Kerberos and is
used improperly. You still have to integrate PKI support and properly
securing access to LDAP with TLS is a whole hell in itself.
 
Documentation is lacking. Distro integration is lacking. Administrative
tools are lacking. 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?

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.

Well just so you know how the things work in the real world... do you know
the best way there is to deploy a directory system for Linux?
 
It's buy a Windows 2008 server and use Samba to integrate Linux into it.
 
That's the most practical and cost effective solution right now for Linux
people wanting to use it in the enterprise.
 
The basic fact here is that Active Directory DOES do it the 'Unix way' with
Kerberos and LDAP (it's just that they did the embrace and extend, but
their extensions are now well documented and support for them exist in MIT
Kerberos and RFC docs). And AD is lightyears ahead of what is available
from a pure OSS solution based on Linux _right_now_.
 
Sure you have support for the protocols and most useful software does have
kerberos and ldap support, but having pieces of software and support for
the protocols does not make it really that useful or cost effective to
deploy. All this stuff existed for years in Linux and most of it mostly
worked, but things are not really improving that well. Even going back 10
years ago with Windows 2000.. that is still a more viable directory
solution for the majority of people then anything possible to do with pure
OSS software.

And the major kicker here is that you _CANNOT_ escape from the fact that
Windows support is going to be a requirement for 99.99% of everybody out
there. There is just too much Windows-only software; too many people stuck
on the Windows desktop and Microsoft Office. Even if 80-95% of the PCs in a
organization are running Linux your still going to need Windows integration
support. You simply cannot escape it. You _CANT_. To simply say that "well
it's possible to do Kerberos and LDAP in Linux" is completely ignoring the
hard requirements for virtually everybody out there.
 
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.
 
In fact Samba4 is probably one of the most critical pieces of software
being developed today.

Samba with Active Directory: getting bigger?

Posted Feb 4, 2010 17:14 UTC (Thu) by drag (subscriber, #31333) [Link]

Sorry. I pressed the wrong button. Here is my post again in a more readable form.

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.

Yeah they do.

Policykit is designed allow policies to be distributed when it comes to system permissions. Whether or not users are allowed to update or install software, mount drives, configure network, etc etc.

Then for the Gnome desktop you have Sabayon for building profiles (default apps, configurations, etc) and Pessulus for providing lock-down policies for the Gnome desktop. 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.

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),

Yes there is. There are huge obstacles to this, like I said in my previous post. It's very hard to do and very error prone and there are huge holes in functionality and management systems not even addressed. Almost nobody does it properly out of the box. Redhat comes closest and they have their Identity management packages and other related items, but that currently mostly for people that need to migrate away from NIS for regulatory reasons. (and most of those people will just migrate from NIS to AD for obvious sanity reasons)

Mandriva MDS seems 'OK' also, but almost nobody uses Mandriva anymore.

There are dozens of configuration changes you have to make. OpenLDAP is a pain to work with, and nsswitch and other things can cause really huge headaches and even booting problems unless you configure them exactly right. PAM is regularly abused by people deploying LDAP and Kerberos and is used improperly. You still have to integrate PKI support and properly securing access to LDAP with TLS is a whole hell in itself.

Documentation is lacking. Distro integration is lacking. Administrative tools are lacking. 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?

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.

Well just so you know how the things work in the real world... do you know the best way there is to deploy a directory system for Linux?

It's buy a Windows 2008 server and use Samba to integrate Linux into it.

That's the most practical and cost effective solution right now for Linux people wanting to use it in the enterprise.

The basic fact here is that Active Directory DOES do it the 'Unix way' with Kerberos and LDAP (it's just that they did the embrace and extend, but their extensions are now well documented and support for them exist in MIT Kerberos and RFC docs). And AD is lightyears ahead of what is available from a pure OSS solution based on Linux _right_now_.

Sure you have support for the protocols and most useful software does have kerberos and ldap support, but having pieces of software and support for the protocols does not make it really that useful or cost effective to deploy. All this stuff existed for years in Linux and most of it mostly worked, but things are not really improving that well. Even going back 10 years ago with Windows 2000.. that is still a more viable directory solution for the majority of people then anything possible to do with pure OSS software.

And the major kicker here is that you _CANNOT_ escape from the fact that Windows support is going to be a requirement for 99.99% of everybody out there. There is just too much Windows-only software; too many people stuck on the Windows desktop and Microsoft Office. Even if 80-95% of the PCs in a organization are running Linux your still going to need Windows integration support. You simply cannot escape it. You _CANT_. To simply say that "well it's possible to do Kerberos and LDAP in Linux" is completely ignoring the hard requirements for virtually everybody out there.

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.

In fact Samba4 is probably one of the most critical pieces of software being developed today.

Samba with Active Directory: getting bigger?

Posted Feb 4, 2010 22:07 UTC (Thu) by buchanmilne (guest, #42315) [Link]

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.

Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 0:22 UTC (Fri) by njs (guest, #40338) [Link]

Wow, thanks for taking the time to write that out; it's very interesting.

Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 10:43 UTC (Fri) by cortana (subscriber, #24596) [Link]

>> 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).

Would you mind going into a little more detail there? I thought the point of PAM is so that every
application does not individually have to implement a horde of
authentication/authorisation/session management/password changing APIs themselves...

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... ;) )

Samba with Active Directory: getting bigger?

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

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.
-------------------------------

To clarify. It NEEDS to be trivial on the client side to integrate into a
domain. It is currently not trivial at all for the most part on the Linux
client side of things. "Should be trivial" was too vague in that context.

Use-Prevention Technology (slightly Off-Topic)

Posted Feb 12, 2010 17:01 UTC (Fri) by Epicanis (guest, #62805) [Link]

Just a philosophical observation, but there's something that really, really bugs me about the fact that "Enterprise" features seem to revolve around use-prevention technologies.

Though it's not by any means exclusively a "Microsoft" thing, this is especially apparent when AD comes up, and it never seems to be about making things more productve so much as preventing people from using their computers. "All the computers have USB ports. How to I keep people from using them?" "The computers have internet access, how do I keep people from using the internet?" and so forth (and the perception that use-prevention features of ActiveDirectory and other technologies somehow magically fix everything).

Yeah, I understand why people feel the need for them, and I don't really have a real alternative to suggest. There's just something that really bugs me about it.

We now return you to your regularly-scheduled ActiveDirectoryFest...

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)

Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 0:00 UTC (Fri) by Kamilion (guest, #42576) [Link]

Tried eBox? It does that.

Setup ebox-usersandgroups for LDAP, ebox-samba for CIFS, and ebox-desktop on your client systems.

Based on Hardy LTS, next one's on Lucid LTS.

http://www.ebox-platform.com

Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 10:45 UTC (Fri) by Felix.Braun (subscriber, #3032) [Link]

Thanks, drag, for taking the time to reply to my post in such detail. The discussion that you helped bring along is very informative.

However, it still doesn't let me compile samba in such a way that it would fit in 32MB of RAM. Yes, you told me that I don't really want to do that, but I'm stubborn kind of guy and I don't see why samba should take several orders of magnitude more code than ftp when all I want it to do is essentially the same. I know that samba can do much more than that, but file sharing with moderate security will be quite enough for my needs. Thank you.

Mind you, I'm not complaining to the samba developers. They scatched their itch. And by doing that they provided everybody with a very good implementation of the CIFS protocol as spoken by Windows. I was just expressing my hope that with the addition of yet another layer of services, it would become more obvious that even with samba, one size does not fit all requirements.

Thanks for pointing out the Sheevaplug. It might turn out that just throwing more horsepower at the problem might be preferrable to cutting down samba in a sane way.

Samba with Active Directory: getting bigger?

Posted Feb 4, 2010 12:23 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Are there any other useful SMB/CIFS servers?

I recently saw http://www.fefe.de/gatling/ . It claims to also have "Read-only SMB support (good enough to read a specific file from Windows or using smbclient from Samba)".

Anything in BusyBox? :-)

Alfresco

Posted Feb 4, 2010 15:43 UTC (Thu) by dmarti (subscriber, #11625) [Link]

Alfresco has its own File Server Subsystem.