While so many seem to see another chance to put the boot into Microsoft, others of us, who work in interoperability every day, are really quite excited by this tool. I was pleasantly surprised when Garming Sam, my colleague at Catalyst and fellow member of the Samba Team, wrote this article on how to run Samba under bash on Windows:
The fact that Microsoft is implementing the POSIX API, and even more, the Linux ABI, seriously is really cool, and shows that something seems to have changed in Redmond. I could never have imagined this when I started in Samba 15 years ago!
Now, I have one last suggestion. On a Windows machine, an AD is setup with a simplistic wizard, where standard AD questions get asked. It seems that such a wizard might be a good idea - even if at the end the wizard advised where to make additional changes. (This might give you a leg up in selling to Windows ops)
I suggest you read our HOWTO when the server recovers, because you will see that our samba-tool domain provision command does exactly that, and the HOWTO covers things from top to bottom. Samba Administrators have been deploying Samba as an AD DC for a number of years now, and they consistently point to these two things as why they find it so easy to do so.
The AD DC is actually is a bunch of core libraries and services. To make things easiest for our users, the services are linked into and started up by one binary, but internally each different task ends up in a forked process (if appropriate). But we do one better, and allow this to be controlled at runtime, so with '-M single' it essentially becomes a giant state machine, and can be handled with a single gdb. Inter-process communication is via a unix domain socket based messaging system or full DCE/RPC pipes.
External processes can register specific named pipes (when, as we do by default, we use smbd as the file server, this is actually a key part of the design), or DCE/RPC server modules can be loaded (the OpenChange project provides such a module).
We could discuss if more or less of Samba's internal communication should use one design pattern or another, but what is more interesting is that without fanfare or bother, some of those ideas, implemented pragmatically rather than dogmatically, have become an essential part of how Samba is implemented. That pragmatism has then brought us the AD DC that we are so proud to announce today.
I also love that the shared libraries that we now use internally make Samba much smaller as well, reducing the disk space overhead.
Finally, a surprising amount of the code is actually in modules on ldb, our ldap-like database at the core of the system.
I know you were hoping to troll with what has been a long-running design philosophy, but when you spend the time building the system, you find the pragmatism rules the day, and we use a variety of tools to get the job done, and to get it done is a way that is most seamless to our users.
You are correct that if things were as bad as that particular paragraph sounds, then we would have a serious issue. That particular note (which I wrote) is over-cautious, and represents where we were at a few months ago. The situation is that when administrators manually attempt to replicate the DNS partition onto another DC, it is difficult to configure everything so that as well as the initial replication, updates are correctly propagated.
The good news is that now, when we are setting Samba up as a second DC, we now do this correctly at join time. From all reports, this seems to work fine, but the warning is there because I want administrators who are having issues in this area to know that some challenges may remain.
Overall, while we have great faith in our DRS replication code, and a large number of users have deployed multiple Samba DCs, we are promoting the single DC case first and foremost. Other limitations include that we cannot replicate the files in the sysvol share (where group policies reside) using native protocols (many of our production sites use an rsync script instead). We are well aware of these limitations, and try to describe them to our users.
You may feel we should have waited even longer to release, but I'm quite happy with what we have achieved, and how our production sites find it in the real world. There is always one more feature, one more bug, but I'm incredibly proud of what we have achieved with Samba 4.0
Indeed, it was seeing the limitations of the NT4 modal that held back these domains that was one of the major reasons I started on the AD DC effort for Samba. I deployed (and indeed was involved in the creation of) a mixed Heimdal/Samba/LDAP domain, and saw how the lack of Group Policy caused real issues for a large network of Windows PCs. In my specialist area of Authentication, I also saw how NTLM authentication did and did not work, particularly in the load it put on the DCs. Kerberos is a much better authentication prototcol than NTLM, and I'm glad that Samba now not only can accept Kerberos authentication, but as the Domain Controller, it can now be the KDC too!
In the same way, I saw the writing on the wall for NT4 support for a long time, and I'm just very glad that the interoperability environment changed enough in time that we were able to get changes made to Samba and Windows to allow Samba NT4-like 'classic' domains to continue, long past when NT4 DCs became not only unsupported, but deliberately broken (in the name of increased security). As you mention it still requires a registry patch however, and so with the release of Samba 4.0 as an AD DC I look forward to Samba administrators being able to deploy a 'just works' solution again, even for the latest windows versions.
I do have to say, the AD interop labs were some of the most fun I've had in IT. And yes, it was great having the food brought in as we worked late into the night, night after night.
The best bits were being able to work side-by-side with their engineers solving some of the trickiest parts of the puzzle, or working over the results of running their testsuite. These things made Samba much better, and I'm happy to say how much we appreciate these opportunities.
Samba uses Heimdal Kerberos precisely because we did not wish to re-invent Kerberos. We bundle a known-working copy of that in the tree, and launch the KDC inside the samba process so it behaves as a seamless part of the AD DC. We provide plugins for the things that need to be AD-specific (such as PAC handling and reading the AD Database) for the Heimdal codebase to use.
For LDAP, we took a different approach, and instead wrote our own LDAP-like database on top of tdb. LDAP is in many ways much simpler at the core, and the hard parts are all the schema rules and special cases that are AD-specific anyway, and which we have special modules to handle (on top of LDB, which remains quite lightweight). That isn't to say that this would not have been possible - indeed, Luke Howard's XAD shows it is - but just that we decided to do that part in-house. I'm quite comfortable with that choice.
I agree, existing OpenLDAP sites using Samba 3.x in cooperation with a host of other packages, using the traditional LDAP directory structure deployed on many Linux oriented sites are not going to migrate to Samba 4.0 as an AD DC any time soon. The change is just as big as the change to migrate to Microsoft's Active Directory, except that we provide a tested upgrade tool to handle the Samba-essential parts.
We want this to be easier, and the tools can certainly be extended to cover other schema items, and integration of these services can improve, because many of these can work well against a Microsoft Windows AD. However, we know this is a big leap, so we continue to support existing configurations (with the existing features. (For want of a better term, we call it a 'classic' domain).
The issue isn't as much being unable to use an LDAP server as a data store (but this became more difficult as we became more like AD), as that unless we were to implement on the fly schema translation, most of the same issues would remain (assumptions about AD or traditional schema and layout between Samba and the other tools on the LDAP backend), and so the result would not have be useful anyway!
As such, the LDAP backend has been put aside as an interesting technical modal that didn't work out. If a plausible use case ever comes up, then interested developers might revive some of it (the code and some tests remain where they are not impeding development), but for now there are no plans for support of anything other than local LDB files and native replication with other AD servers.
People are free to install AFS clients on NT if they want - even NFS clients are available. But there is one major problem - almost nobody does!
Samba succeeds becouse it does not require client modifications - you can swap in and out the server equipment without changing your thousands of clients.
And even if we were to create a 'Client for Unix Networks', it would not make the job easier anyway - most of the issues we come up against are in emulating NTFS semantics, in comparison pushing these onto CIFS is easy....
Doing this on the sever-side really is easier - we have the LDAP user management already. The other things you list are really seperate tools - there is no reason why a tool like Novell's ZEN system can't work without replacing the network client, and no reason why such a tool cannot be developed.
This comment is misleading. There are no plans for samba.org to release Samba TNG, they are there own project now, and we have our own development process that is producing a very nice PDC for 3.0.
Samba 2.2 contained basic domain control capabilty, and 3.0 really does a good job of completing it.
Also, Samba 3.0 does many things that TNG does not - in particular Active Directory client support, and even Active Directory DC developement (very early)
Incorrect. Microsoft's LDAP server supports SASL binds - in particular it supports GSSAPI. This is the feature Samba 3.0 (currently in alpha) is using to authenticate to an AD installation.
Its actually quite sane - and the problems we have had in developing with it have not be AD, its been the unix client tools making assumptions about a functioning DNS (hint: it doesn't exist on MS networks).
But with a few config file tweaks its perfectly practical to kinit to your AD KDC and use that for a secure authenticaion! (In the end Tridge rewrote our own mini implemenation of the required peices to work around the buggy SASL libs).
As a year 12 student at Hawker College (serving year 11 and 12 students in Canberra, AU) I setup the student server project, and it was entirly student-run operation. I also ran the proxy server and incresing large sections of the basic network infrustrucure. I am now a uni student, and I am engaged profesionally to continue my work on the schools collection of Linux based computers (all of which I setup).
However this could not have been done without the support of the IT staff, and they now do the day-to-day adminstration of the system - But I am the only one with root. Over the 12 months I ran the system as a student I was able to bring incresing numbers of staff on-board, and it is the support of these staff that means that the project lives on. The project will also continue as a 'student server', once the new students settle down, simply to find persons with the applicable talent.
It is only thought the respect that I had gained as a student and the garantees that I made that my changes would not affect the operation of the existing network that this was able to occour - without these the project could not have got off the ground.
The main problem with student-run IT is finding the 'right' talent - finding honest, reliable, trustworthy people who also have the applicable talent and the time to use it is harder (at least at my college) than you might think.
And when you run on a spot market, power on 30 seconds notice can be sold for quite a tidy profit. (Even power on 10 minutes notice, the way these plants normaly work, can be sold for quite a tidy profit).
These plants make their money becouse off-peak power is cheap but on-peak power can be very expencive.
Well PAM does implement ACLs, just not in the file-permissions case, its ACLs are for logins and the like. (It does get into some file-permission stuff, for things like the console user permissions, but these are done by modifying the permissions on actual files).
PAM has NOTHING to do with xrw style permissions, this is somting else, called ACLs (Access Control Lists).
PAM authenticates users in a flexable manner, and allows much more fine grained control than the traditional/etc/passwd only system. RedHat uses this to allow authentication against Kerebos, NIS and the like. Furthermore RedHat's recent steps in their implementation of PAM in RedHat 7 allow global configuration of all PAM services from one file (/etc/pam.d/system-auth).
In Australia the Fedral government pays authors a small royalty for 20 years after publication, based on a few cents per time their book is borrowed from a Public Library. This is meant to be a small compensation for what would otherwise be royalties from book sales.
It sounds like setting up a IP alias would be the only hassle, then just setup Samba to listen on one and Samba-TNG to listen on the other. (Remember they both listen on the same netbios ports).
On the insert speed of PostGreSQL, use the COPY command, it works a lot faster. (I get in 20 Mins with copy for what takes hours with individual inserts).
In fact myopia can be greatly incresed by constantly staring at that screen. I know becouse I just talked to a practicing Behavioral Optometrist, who specialises in this kind of area.
Slashdot Mirror
While so many seem to see another chance to put the boot into Microsoft, others of us, who work in interoperability every day, are really quite excited by this tool. I was pleasantly surprised when Garming Sam, my colleague at Catalyst and fellow member of the Samba Team, wrote this article on how to run Samba under bash on Windows:
https://www.samba.org/~garming...
The fact that Microsoft is implementing the POSIX API, and even more, the Linux ABI, seriously is really cool, and shows that something seems to have changed in Redmond. I could never have imagined this when I started in Samba 15 years ago!
Now, I have one last suggestion. On a Windows machine, an AD is setup with a simplistic wizard, where standard AD questions get asked. It seems that such a wizard might be a good idea - even if at the end the wizard advised where to make additional changes. (This might give you a leg up in selling to Windows ops)
I suggest you read our HOWTO when the server recovers, because you will see that our samba-tool domain provision command does exactly that, and the HOWTO covers things from top to bottom. Samba Administrators have been deploying Samba as an AD DC for a number of years now, and they consistently point to these two things as why they find it so easy to do so.
Andrew Bartlett
Samba Team
OpenChange, mentioned in the summary, handles the Exchange protocols. We are very proud of the close way we work with the OpenChange team.
Andrew Bartlett
Samba Team
The AD DC is actually is a bunch of core libraries and services. To make things easiest for our users, the services are linked into and started up by one binary, but internally each different task ends up in a forked process (if appropriate). But we do one better, and allow this to be controlled at runtime, so with '-M single' it essentially becomes a giant state machine, and can be handled with a single gdb. Inter-process communication is via a unix domain socket based messaging system or full DCE/RPC pipes.
External processes can register specific named pipes (when, as we do by default, we use smbd as the file server, this is actually a key part of the design), or DCE/RPC server modules can be loaded (the OpenChange project provides such a module).
We could discuss if more or less of Samba's internal communication should use one design pattern or another, but what is more interesting is that without fanfare or bother, some of those ideas, implemented pragmatically rather than dogmatically, have become an essential part of how Samba is implemented. That pragmatism has then brought us the AD DC that we are so proud to announce today.
I also love that the shared libraries that we now use internally make Samba much smaller as well, reducing the disk space overhead.
Finally, a surprising amount of the code is actually in modules on ldb, our ldap-like database at the core of the system.
I know you were hoping to troll with what has been a long-running design philosophy, but when you spend the time building the system, you find the pragmatism rules the day, and we use a variety of tools to get the job done, and to get it done is a way that is most seamless to our users.
Andrew Bartlett
Samba Team
The bind9_dlz backend uses the same database as the rest of Samba, and so suffers the same features and limitations as the overall DC.
As I said in the other post, while we are concerned about this area, so far this does not appear to pose an issue in practice.
Andrew Bartlett
Samba Team
You are correct that if things were as bad as that particular paragraph sounds, then we would have a serious issue. That particular note (which I wrote) is over-cautious, and represents where we were at a few months ago. The situation is that when administrators manually attempt to replicate the DNS partition onto another DC, it is difficult to configure everything so that as well as the initial replication, updates are correctly propagated.
The good news is that now, when we are setting Samba up as a second DC, we now do this correctly at join time. From all reports, this seems to work fine, but the warning is there because I want administrators who are having issues in this area to know that some challenges may remain.
Overall, while we have great faith in our DRS replication code, and a large number of users have deployed multiple Samba DCs, we are promoting the single DC case first and foremost. Other limitations include that we cannot replicate the files in the sysvol share (where group policies reside) using native protocols (many of our production sites use an rsync script instead). We are well aware of these limitations, and try to describe them to our users.
You may feel we should have waited even longer to release, but I'm quite happy with what we have achieved, and how our production sites find it in the real world. There is always one more feature, one more bug, but I'm incredibly proud of what we have achieved with Samba 4.0
Andrew Bartlett
Samba Team
Indeed, it was seeing the limitations of the NT4 modal that held back these domains that was one of the major reasons I started on the AD DC effort for Samba. I deployed (and indeed was involved in the creation of) a mixed Heimdal/Samba/LDAP domain, and saw how the lack of Group Policy caused real issues for a large network of Windows PCs. In my specialist area of Authentication, I also saw how NTLM authentication did and did not work, particularly in the load it put on the DCs. Kerberos is a much better authentication prototcol than NTLM, and I'm glad that Samba now not only can accept Kerberos authentication, but as the Domain Controller, it can now be the KDC too!
In the same way, I saw the writing on the wall for NT4 support for a long time, and I'm just very glad that the interoperability environment changed enough in time that we were able to get changes made to Samba and Windows to allow Samba NT4-like 'classic' domains to continue, long past when NT4 DCs became not only unsupported, but deliberately broken (in the name of increased security). As you mention it still requires a registry patch however, and so with the release of Samba 4.0 as an AD DC I look forward to Samba administrators being able to deploy a 'just works' solution again, even for the latest windows versions.
Andrew Bartlett
Samba Team
I do have to say, the AD interop labs were some of the most fun I've had in IT. And yes, it was great having the food brought in as we worked late into the night, night after night.
The best bits were being able to work side-by-side with their engineers solving some of the trickiest parts of the puzzle, or working over the results of running their testsuite. These things made Samba much better, and I'm happy to say how much we appreciate these opportunities.
Andrew Bartlett
Samba Team
Samba uses Heimdal Kerberos precisely because we did not wish to re-invent Kerberos. We bundle a known-working copy of that in the tree, and launch the KDC inside the samba process so it behaves as a seamless part of the AD DC. We provide plugins for the things that need to be AD-specific (such as PAC handling and reading the AD Database) for the Heimdal codebase to use.
For LDAP, we took a different approach, and instead wrote our own LDAP-like database on top of tdb. LDAP is in many ways much simpler at the core, and the hard parts are all the schema rules and special cases that are AD-specific anyway, and which we have special modules to handle (on top of LDB, which remains quite lightweight). That isn't to say that this would not have been possible - indeed, Luke Howard's XAD shows it is - but just that we decided to do that part in-house. I'm quite comfortable with that choice.
Andrew Bartlett
Samba Team
I agree, existing OpenLDAP sites using Samba 3.x in cooperation with a host of other packages, using the traditional LDAP directory structure deployed on many Linux oriented sites are not going to migrate to Samba 4.0 as an AD DC any time soon. The change is just as big as the change to migrate to Microsoft's Active Directory, except that we provide a tested upgrade tool to handle the Samba-essential parts.
We want this to be easier, and the tools can certainly be extended to cover other schema items, and integration of these services can improve, because many of these can work well against a Microsoft Windows AD. However, we know this is a big leap, so we continue to support existing configurations (with the existing features. (For want of a better term, we call it a 'classic' domain).
The issue isn't as much being unable to use an LDAP server as a data store (but this became more difficult as we became more like AD), as that unless we were to implement on the fly schema translation, most of the same issues would remain (assumptions about AD or traditional schema and layout between Samba and the other tools on the LDAP backend), and so the result would not have be useful anyway!
As such, the LDAP backend has been put aside as an interesting technical modal that didn't work out. If a plausible use case ever comes up, then interested developers might revive some of it (the code and some tests remain where they are not impeding development), but for now there are no plans for support of anything other than local LDB files and native replication with other AD servers.
Andrew Bartlett
Samba Team
I am unaware of any issues - Win2k3 is our standard test platform.
Are you referring (on Linux) to smbfs, and have you looked into cifsfs instead?
People are free to install AFS clients on NT if they want - even NFS clients are available. But there is one major problem - almost nobody does!
Samba succeeds becouse it does not require client modifications - you can swap in and out the server equipment without changing your thousands of clients.
And even if we were to create a 'Client for Unix Networks', it would not make the job easier anyway - most of the issues we come up against are in emulating NTFS semantics, in comparison pushing these onto CIFS is easy....
Doing this on the sever-side really is easier - we have the LDAP user management already. The other things you list are really seperate tools - there is no reason why a tool like Novell's ZEN system can't work without replacing the network client, and no reason why such a tool cannot be developed.
This comment is misleading. There are no plans for samba.org to release Samba TNG, they are there own project now, and we have our own development process that is producing a very nice PDC for 3.0.
Samba 2.2 contained basic domain control capabilty, and 3.0 really does a good job of completing it.
Also, Samba 3.0 does many things that TNG does not - in particular Active Directory client support, and even Active Directory DC developement (very early)
NTLMv2 authentication is fully supported in Samba 3.0 - we brought the code across from TNG 18 months ago.
:-).
Recent alphas have LMv2 authenticaion too
The truth is, almost nobody uses NTLMv2 - certainly not MS...
Incorrect. Microsoft's LDAP server supports SASL binds - in particular it supports GSSAPI. This is the feature Samba 3.0 (currently in alpha) is using to authenticate to an AD installation.
Its actually quite sane - and the problems we have had in developing with it have not be AD, its been the unix client tools making assumptions about a functioning DNS (hint: it doesn't exist on MS networks).
But with a few config file tweaks its perfectly practical to kinit to your AD KDC and use that for a secure authenticaion! (In the end Tridge rewrote our own mini implemenation of the required peices to work around the buggy SASL libs).
Andrew Bartlett,
Samba Team
As a year 12 student at Hawker College (serving year 11 and 12 students in Canberra, AU) I setup the student server project, and it was entirly student-run operation. I also ran the proxy server and incresing large sections of the basic network infrustrucure. I am now a uni student, and I am engaged profesionally to continue my work on the schools collection of Linux based computers (all of which I setup).
However this could not have been done without the support of the IT staff, and they now do the day-to-day adminstration of the system - But I am the only one with root. Over the 12 months I ran the system as a student I was able to bring incresing numbers of staff on-board, and it is the support of these staff that means that the project lives on. The project will also continue as a 'student server', once the new students settle down, simply to find persons with the applicable talent.
It is only thought the respect that I had gained as a student and the garantees that I made that my changes would not affect the operation of the existing network that this was able to occour - without these the project could not have got off the ground.
The main problem with student-run IT is finding the 'right' talent - finding honest, reliable, trustworthy people who also have the applicable talent and the time to use it is harder (at least at my college) than you might think.
And when you run on a spot market, power on 30 seconds notice can be sold for quite a tidy profit. (Even power on 10 minutes notice, the way these plants normaly work, can be sold for quite a tidy profit).
These plants make their money becouse off-peak power is cheap but on-peak power can be very expencive.
Well PAM does implement ACLs, just not in the file-permissions case, its ACLs are for logins and the like. (It does get into some file-permission stuff, for things like the console user permissions, but these are done by modifying the permissions on actual files).
I agreee, it should be in the FAQ.
Just a quick correction:
/etc/passwd only system. RedHat uses this to allow authentication against Kerebos, NIS and the like. Furthermore RedHat's recent steps in their implementation of PAM in RedHat 7 allow global configuration of all PAM services from one file (/etc/pam.d/system-auth).
PAM has NOTHING to do with xrw style permissions, this is somting else, called ACLs (Access Control Lists).
PAM authenticates users in a flexable manner, and allows much more fine grained control than the traditional
In Australia the Fedral government pays authors a small royalty for 20 years after publication, based on a few cents per time their book is borrowed from a Public Library. This is meant to be a small compensation for what would otherwise be royalties from book sales.
It sounds like setting up a IP alias would be the only hassle, then just setup Samba to listen on one and Samba-TNG to listen on the other. (Remember they both listen on the same netbios ports).
It could end up being quite a win-win situation.
On the insert speed of PostGreSQL, use the COPY command, it works a lot faster. (I get in 20 Mins with copy for what takes hours with individual inserts).
In fact myopia can be greatly incresed by constantly staring at that screen. I know becouse I just talked to a practicing Behavioral Optometrist, who specialises in this kind of area.
See http://www.oregoneyecenter.com/myopia.htm