I suppose someone had to post this message at some point, so I thought "why not me?".
Single-Sign-On is widely heralded as the holy grail of computing. So: Microsoft have created the Services For Unix add-on to their popular Windows Server System which adds optional RFC2307 entries into the Active Directory LDAP database (on domain controllers). The important part of this is UID/GID allocation, which the upcoming Samba 3.0.25 will support natively with it's WinBind system. (When Samba is joined to an AD domain winbind will utilise the UID/GID entries set up in the RFC2307 fields.) This effectively means that, if one can come up with a way of entering user data directly into the Active Directory from VirtualMin complete with the RFC2307 entries, single-sign-on with all *ix and Windows boxes in the network will be possible.
Another bonus of this research is that, when you can directly create entries in the AD database from Virtualmin, porting the entire system to a windows server would become somewhat easier, as the user and group creation has already been addressed. The next step in porting to Windows would be to decide whether to use native Windows services (IIS etc.) or install Apache and Postfix on the windows box. When using native Windows systems you don't need to worry about the authentication stuff, as everything has AD auth already built in, and just needs setting up to reference the correct user (tho, I'm unsure about an suexec-type system for Windows). If using Postfix on a windows system, there is the problem of auth data for the SASL stuff along with questions as to where Postfix gets it's list of local users from. MySQL is not a problem as it auths against it's own database. Apache is not a problem if we just use one username for the processes, but there are issues when thinking about suexec. This issue with suexec can be overcome, though, by using the Interix-based POSIX subsystem installed by the Service For Unix package to run Apache in a native POSIX environment with full support for user context switching.
My ideal system is to use Windows as the backing store for files and users/groups, exporting the users and groups to Samba/Winbind, and setting up an NFS file share for the user home directories. Then my CentOS box with Virtualmin on will import the users/groups/files via NFS and Winbind. This would allow me to provision as many windows boxes as I need into the AD domain, and as many Linux boxes authenticating against the AD domain via Samba. This will allow me to set up SSO-based distributed SSH on my mini-cluster (when turned on), have proper network-based auth in my desktop machines running Windows, and finally when I boot a desktop into linux I will be able to login using the same username and password as in windows.
Hey Daniel,
Talk about opening a can of worms! Good topic for a Monday. ;-)
I didn't know about the new AD and Samba UID/GID stuff. That's an interesting one. I won't rule out the possibility of adding AD support to our existing LDAP support. I'm not promising it, either, of course...as we've never really heard much interest in Windows support of any kind in Virtualmin, and it's way down the list in the voting for operating systems to support. It could be a self-fulfilling prophecy, however...we don't support Windows, so no Windows users show up to talk about it or ask for it.
If we did support it, we'd probably stick with Apache, rather than IIS, for a number of reasons. Though I can see value in "going native". But, going native would be a HUGE time sink. We'd definitely have to hire on a serious Windows guy to handle support and some of the development (so this would have to come after we take on outside investment, and only after we hash out what our biggest customers are looking for from Virtualmin...if we sign on a top ten hosting provider as a customer and they want Windows support, we will add Windows support).
But, in the short term, AD sounds do-able. We'll look into it when the new Samba version begins to show up as a standard component of some Linux distributions.
--
Check out the forum guidelines!
I've been perusing the MSDN website, too, and found documentation that seems to imply that all the standard ldap_add features are supported by AD as part of their LDAP compliance (which would explain how projects like phpldapadmin work with it). This is interesting, as the only thing to worry about, once you realise that the ldap users and groups module could handle it, is making sure that the module adds the appropriate entries required by Microsoft's schema.
Another thing I happened across, is that it seems that Samba 3.0.24 actually does the UID/GID mapping from AD's RFC2307 entries too, it's just the .25 release will have rewritten idmap stuffs which enhance the support, so who knows how long they've had this facility? :-p.
A quote from the help manual for "Active directory users and groups" management console:
(This text is copyright to Microsoft, and I am unsure as to the redistribution or quoting rights)
----
InetOrgPerson accounts
Active Directory provides support for the InetOrgPerson object class and its associated attributes defined in RFC 2798. The InetOrgPerson object class is used in several non-Microsoft LDAP and X.500 directory services to represent people within an organization.
Support for InetOrgPerson makes migrations from other LDAP directories to Active Directory more efficient. The InetOrgPerson object is derived from the user class and can be used as a security principal just like the user class.
When the domain functional level has been set to Windows Server 2003, you can set the userPassword attribute on InetOrgPerson and user objects as being the effective password just like you can with the unicodePwd attribute.
----
So this raises the question as to whether Samba supports an active directory domain that has had it's "functional level" raised to "Windows Server 2003" mode in the "Active Directory Domains and Trusts" management console. This mode restricts servers to being windows server 2003 only, so Samba acting as a client may work.
the following page states that while you can't use Samba in a fully native Windows 2003 domain as a domain controller (PDC or BDC), but you can use it as a client and member server.
http://techxworld.com/community/blogs/interop/archive/2007/01/08/using-s...
Please allow me to un-bury this merry old topic, but I think it is appropriate. :)
I was wondering if, replacing this "fully integrating AD" idea, it might be feasible to just perform the authentication part of password-protected website access by querying a domain controller.
I'm administering the IT stuff of our department/working group at University, and I'm pondering to move all our web hosting to Virtualmin. Currently I'm using a "home-brewed" Apache setup on Windows Server 2k3.
We also have a Windows domain. So, most websites which require access rights, pull the authentication from the domain controller using Apache's LDAP module, so our users can use the same credentials in as many places as possible. I'm adding an example config set below.
Would it be possible, in addition to configuring local Linux users for Virtualmin "access to protected web page directories", to fetch the users from an Active Directory?
Of course I can still configure the required Apache directives manually. But since we're in the "discussions" section here, I was wondering if this might be a worthwhile addition to Virtualmin. :)
Here's how I do the authentication now: