Joing Linux to a Windows Domain

[stack]

Hey guys,
Got a few questions I hope people can answer (or point me to information that can answer it).

Right now at work we have 2 little worlds on our network. We have the big Windows 2k3 exchange/active directory/ntp/dns/dhcp/so-forth-and-so-forth-ect domain. Then we have the Linux PC's that well....they just do whatever they are told and they just run. No domain or anything on these guys. I manually update/manage/nsupdate/samba the systems to play nice with Windows on a case-by-case basis. I run primarily Debian stable (currently Etch, will be Lenny soon) and CentOS 4 (4.7 just released like a week ago so I am slowly migrating to that so I have a mixture of 4.4 - 4.7)

Well we have this project that has come up that it would really be nice if the Linux box was on the Windows domain. It would really make things easier for almost every party if a user could log into the Linux system in the same manner they do on their XP system. So I started my research.

Now I have not done it yet, but I am 95% confident that I could join a Linux box to the Windows domain using LDAP, Samba, and Winbind; after all most of the windows domain principles/standards came from the Unix world with the help of At&T. You should have seen the looks on the faces of the Windows admins when I presented that to them (I really had to struggle not to laugh at the sheer pale-faced wide-eyed horror). Anyway, lets just say there is some reserve about problems that might arise. This made me think that even if they give me the thumbs up to proceed, should there be even the slightest hiccup (perceived, real, or imaginary) guess who they are going to blame in a blink of an eye? I am not a Windows guy and the last thing I need to be doing is debugging MS blue screens to find the problem and prove Linux didn't do it. So now I have a few options.

1) Just suck it up and go the more difficult route of this project and keep Windows separated from Linux.
2) Join to the domain and hope everything works as advertised (on both sides of the fence; Linux and windows).
3) Find an alternative method....

Step three is what I am kinda working on now.
----Possible alternative 1----
I found this quote on Wikipedia when researching Active Directory ( http://en.wikipedia.org/wiki/Active_Dir ... _Directory ).

An alternate option is to use another directory service such as Fedora Directory Server (formerly Netscape Directory Server) or Sun Microsystems Sun Java System Directory Server, which can perform a two-way synchronization with Active Directory and thus provide a "deflected" integration with Active Directory as Unix and Linux clients will authenticate to FDS and Windows Clients will authenticate to Active Directory.

I have never heard of such a thing (then again I am not a Windows guy so I don't mess with Windows domains much).
Does anyone have any experience with this? Are there any other alternatives to the listed services?

If "two-way synchronization" means what I think it means, then that sounds like it could be what I am looking for.

----Possible alternative 2----
I also am doing research on SME that was presented at the last meeting. I don't know if this really is possible, but I am thinking if I join all of the Linux systems to their own domain, then I might be able to join the domains in a trusted relationship. Then the two are kept separate but can still interact.

----Possible alternative 3----
I keep digging up information on products like IBM's Tivoli, HP's Openview, and Red Hats Satellite. Now at this time, I have just begun researching these products but I found a source through a GIS that said these products allow for managing many systems from setting up NFS, to adding a user, to managing package updates/installations. Anyone know of some open source tools for doing this? My thought is that if I can control all of the Linux systems from a single host template then setting up a single Linux system on the domain and patching through things like NFS mounts would be a piece of cake!

I will be researching this quite a bit over the next week or so; I will keep you guys updated on what I find. I would appreciate any comments, especially from those who are managing a mixed environment domain where it is Linux joining the Windows domain.

Thanks!
~Stack~

[Randy]

Stack,

I've done this many, many years ago at another job. Now, I'm going by memory here. So, forgive me if this list isn't complete. You'll need Samba and its associated tools, Winbind, Kerberos, OpenLDAP, and the ability to add a computer to Active Directory.

However, reading over everything that you wrote leaves me with a question: What are you trying to accomplish by joining Linux to Active Directory? I'm not sure what the goal is. And, is it really necessary to have two-way synchronization if all you're going to use AD for is authentication and access-control?

A suggestion would be to try this in a lab environment with a machine that has your production replicated data from Active Directory as part of the setup. Your Windows guys could bring another domain controller on-line, acquire the necessary data, and take it out of the production environment with very little disruption (if they know what they're doing). Or, a better idea would be to ghost one of the domain controllers and dump that back to another machine in the lab environment. It would be faster and less disruptive. Once it's in the lab, the functionality can be bumped up to a master/PDC (I forget the actual term). You could then run your tests on joining the two together before trying this on any of your production systems. And, you'll need a back-out plan if things don't go well.

For the most part, it is (used to be?) a safe operation if you're only pulling user/group information for authentication and access-control purposes. Winbind simply copies the users/groups from Active Directory and you set up your security on the Linux box to make use of that data. I'm leary of the two-way synchronization as that implies that the Linux box can update/make changes to the Active Directory domain/forest. I'd want to know more about how that mechanism works before I'd go down that path.

Anyway, there's my two cents (now inflated to five dollars thanks to the financial markets bail-out!)...

A quick check on Google came up with this - http://www.enterprisenetworkingplanet.c ... hp/3487081

It should be a good reference point to get started. I also have a Samba book somewhere, but I'm not sure if it covers Samba 3.x or if it's only for 2.x. I'll check tonight..

[Insanity5902]

I've done this several times, and there are a few different ways.

It really depends on what all you are wanting to do. I have background of doing Windows Administration, and have done Linux administration on the side, haven't had the pleasure of doing as my mian job.

The best way to find out what method you want, is to really define what you are trying to do. Quick AD overview, everything in AD is an object, users and computers can be seen as the same thing, and have their own way of authenticating. If you just need your users to authenticate, then pam_ldap and along with the tools in openldap will provide you with everything you need. You will end up modifing the pam logins, and modifying nsswitch.conf to search ldap for users. Depending on the version of your AD Domain Controller, you will have to modify the attributes on what AD LDAP field is match to the user field needed for login. 2003 R2 provides this built in, 2003 and older you can install the NIS Schemas to provide Unix information.

If you need the computers themselves to authenticate on the domain then you will need to use samba, winbindd, and kerebos. This is a bit more involved, but then it will show the linux server inside AD. I'll be honest, I'm not sure what the benefit of this way is. Going this route I think you might be able to provide a SSO type experience when trying to browser windows shares, but I haven't been successfully in acheiving that. The best SSO for Linux is using Gnome or KDE's keychain store.

As for Fedora Directory Service, it is basically doing the first mentioned option. Use synchronizes everything using openldap, but then it will also provide the NIS type attribute needed for Linux authentication, meaning less modification to an older AD and/or less modification the the client machines. There are multiple synchronization options with FDS, one of this is two-way, you can also do one-way so it just reads the data and will always override exiting data in case of conflicts. You can use FDS as a cheap way to provide backup DC's.

SME just seems to be a distro wrapped these different tools, I wasn't there at the last meeting, so can't accuratly comment on this possiblity

As far a 3 goes, it more outside the scope of what it "sounds" like you are trying to do. These allow you to actively manage a domain of machines. Red Hat's Satellite is what they use to manage the machine on the subscribitions, right now it really only works with RedHat and so possibly CentOS, it just queries a server and provides a web interface to all the software adn settings. Not sure if you can push features and settings out with this. Not sure about Tivoli and OpenView. There are alot of ways to manage Unix domains. NIS is a way to do central authentication, but it being replaced with OpenLDAP. And now that ldap is supported by PAM and with the release of 2003 R2, I'd imagine you would start to see AD used a lot more for Unix authenication in the Exsiting corporate enviroments. There are programs out there like cfengine that will help mange and push configuration files. And then with your distro's of choice you can package up applications and "stages" that have prebuilt apps and configurations. I use Gentoo mainly, so my knowledge is with emerge and catalyst system to build stages and push out tarballs to lots of machines.

If I think of anything else I will provide it, in the meantine, if it is possible for you to provide more what you are thinking of doing it might help it coming up with a better solution.

[stack]

Thanks for the replies!

I have done a bit more research and I have a better understanding then when I first posted. However, I am still far off from perfect understanding. I really appreciate your input.

The reasons why I am attempting to do this:
3) There are a number of computers on the domain that host a website (IIS and Apache). When a system not joined to the domain tries to access these sites they must supply computer.domain.com and then provide authentication. The systems joined to the domain simply access computer and the authentication happens behind the scenes. If my understanding is correct this would also affect things like rdesktop.

2) There exists a user with an account on both the Windows domain and on the Linux systems. The domain forces a new password every 90 days. This user wishes to have the same password on the Windows systems as the Linux systems. So far I have just taken the lazy approach and I wrote a small shell script that easily allows me to update his password across the ~10 Linux systems the user actually uses. It is not ideal and I know there are better methods of dealing with it in the Linux world. From what I have read it should be possible to have the password filter down from the domain and update the Linux boxes and this would eliminate the problem altogether .

1) This is the big one. http://www.redmine.org I have not used this seriously before (just toyed with it a bit) but it appears to be favored by several of the developers. They wish to expand this out to others in the company but do not wish to maintain individual logins/accounts for everyone (In fact the project will be handed off to me soon so that they can develop and not maintain ). I have been told that by setting up LDAP on Redmine and joining the Linux system to the domain, then the domain user/pass can be used to grant access. Any comments welcome as I have only just now really begun researching it.

I have already spoken with one of the Windows Admins about setting up a testing domain modeled after the one in use; they don't really have a testing lab for most of their servers which surprises me. Anyway, I hope that I will have access to that soon.

Also, I have done a bit more research on Red Hat's Satellite. It is really cool stuff in how they have a single tool to manage multiple servers in various states and functional roles. However, it is not what I initially thought it was and I have to agree with Insanity5902 in that it is out of the scope of this project.

Thanks for the replies!
~S~

[Insanity5902]

Lets see if I can get all of this

3) In theory, it should be possible, but I haven't been able to do this. This type of setup would require a Samba/Winbindd route. Another way to get around this is to use the keychain management inside of KDE or Gnome. This is currently what I do. I use Gnome's keyring, which gets unlocked when I log in. Then it stores the logins of all my logins (ssh, ftp, windows share) and gets me in. I don't think there is a way around rdesktop, as that is now the default in windows to ask for the pass.

2) You can easily achieve this with pam-ldap setup. You will just need to be a bit creative when mapping the uid and gid of a user if you are running on a domain < 2003 R2. If you can install the NIS patch for AD, then you can get around that also. Other wise you will need to map the unix user fields to different AD fields. I don't remember the ones I used off hand.

1) This is extremely easy, and doesn't require pam-ldap. Ruby has it's own ldap built in, you just need to provide it with the server name and a "scout". I use the term scout as that is the user name I use, it has bare minimum privileges on the domain, and a decently difficult password, but yet easy to remember. This account is just used to bind to the domain to perform searches. I have this set up currently at my office. This combined with Redmine's auto-user creation, all you have to worry about from that point forward is permissions per project.

Let me know as you get further into it, or have more questions. I am sure more will come to me when ask

[stack]

Sweet! Thanks for the info!

Just so you know our time-line and what I am doing.
Sometime soon, Debian is releasing Lenny as stable. When they do, we are migrating our Debian servers to Lenny. After that migration (probably a week or two because I like to take migrations slowly), I am to install Red Mine and get it working. Until then, I am going to be researching this as best as I can and I am putting pressure on the Windows Admins to supply a functional test domain for me to play with. I am hoping that by the time I have to install Red Mine on our production servers that I will have the process down.

I appreciate your help! Thanks again!
~S~

[Insanity5902]

Not a problem.

Here is some information to get you going with LDAP searching and such.

The Base DN is where you want o start looking, this is defined using a series of descriptors (for lack of a better term). Your domain is defined with dc, so testbed.mycompany.local domain is dc=testbed,dc=mycompany,dc=local. To further define a BaseDN is you can add in the OU's and such. What killed me for the longest time is that Windows AD includes some default folders (i.e. Users, Computers, etc) These are defined with CN, and folder you create in the AD is defined as OU. So if underneath users you have a folder named HomeOffice, you would set it as the BaseDN like ou=HomeOffice,cn=Users,dc=testbed,dc=mycopmany,dc=local

Pretty simple.

So when setting up Redmine, you will give it the IP of your Domain Controller, and then specify the "scout" user I used the format of scout@testbed.mycompany.local and it worked. You will set your BaseDN, which will search this folder and all underneath it. Under the attributes section, these are mapping the redmine user fields to AD fields. So for login, this will more then likely be sAMAccountName (case and spaces matter), Firstname is givenName, Last Name is sN, and Email is mail.

Those are the basic mapping, you could do whatever you want.

Luma is a good OpenSource app for browsing a LDAP server, it will show you all the nitty gritty about the AD layout.

[Insanity5902]

Hey Stack, found some cool stuff today

It's called Zivios And it looks to be AD for Linux. It manages computers CA Certs, dhcp, dns, time, user auth, and probably more.

It looks very cool. While it might not solve your issue of signing onto a windows domain, it might help you manage the linux machines in your enviroment, especially if you don't have any scripts or tools to do this automatically.

Here is a how-to forge article on it http://www.howtoforge.com/using-zivios- ... management

**Edit - also found this http://practical-tech.com/operating-sys ... ng-easier/

[stack]

Sweet! Thanks!

I am setting up some systems to play with this right now. Hopefully I can give you an update on it at the meeting this week.

[Insanity5902]

Just found this article on Technet http://technet.microsoft.com/en-us/maga ... 28986.aspx

Has to do with joining Linux to Active Directory. Talks about 3 different methods and their differences, very informative. It list the pro's of using Winbind vs. LDAP. The two con's they list to using LDAP is that it doesn't use the DNS Locator for the DC (the server is hard coded) and it is inherentily insecure. You could use SSL, but that requires manage the Certs and CA's. The other knock against LDAP is it isn't the native password encryption. By default AD uses Kerebos and then falls back to NTLM. Where LDAP uses basic LDAP binding. IMHO that is a small issue.

The two plusses to using winbind, it provides a method of located the DC, so it isn't hard coded, and then it uses Kerebos for authentication, the native way to do it in AD.

The article then goes through the process of installing Samba on RHEL 5 and setting up the necessary apps for winbind to work.