Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Scott Ehrlich wrote: > None of the web pages I've visited thus far have helped me configure > my test C5 box to allow me to successfully at least log into the > console of my C5 box with my AD credentials. Disclaimer: We sell Centrify, but I'm not a salesman. I spent ages looking for a solution that I didn't spend hours of every work week dealing with frustrating issues on, or days of my life configuring and testing to get to work. I discovered Centrify, and now that's all we support for our customers. We'll let them use either Winbind or LDAP, but their on their own with it. Centrify just works. A few things: o I have done this with RedHat o It's been marginally successful at best o using "authconfig" for AD binding seems to work fine, when it works When it does work, using authconfig or authconfig-gtk do work. You'll want to learn how to use LDAP search to troubleshoot things. You'll also want to know all about DNS, NTP and things like FQDNs, CNs, OUs, and sAMAccountNames (All AD objects). I spent a lot of time learning all sorts of things about both LDAP and the underlying structure of Active Directory just to get all this to work in any sort of way that was remotely usable. The problem is that everything needs to be _perfect_ on the AD side, and even if it is now, it won't be 6 months from now. Active Directory often breaks the underlying objects in ways that at least partially makes it difficult for non-Windows systems to deal with (and some Windows systems). It also contains lots of LDAP-like things that are broken as far as true LDAP is concerned, but then again, Windows machines don't really use that. Things like default referrals that point nowhere, references to objects that no longer exist, group memberships that aren't really there anymore, etc. As far as a reference, there are lots of references on the RedHat stuff that should be pertinent to what you're doing. You're on the right track from what I've read: o make sure everything has A & PTR records in all DNS servers o make sure the date/time and TZ match between CentOS and DC o configure Kerberos (krb.conf) and 'kinit' a ticket for yourself. o use authconfig or authconfig-gtk to bind You may need to modify nsswitch.conf for DNS, but I can't recall. If it doesn't bind, try quitting authconfig and using the 'net' command to join: net ads join ?U administrator This will give you the messages that the GUI hides from you. Even then, expect it not to work, or not to work well. Problems with the binding process are most often to do with time mismatches, missing DNS lookups, or incorrect FQDNs. Things you'll encounter with binding using Winbind are: o server becoming unusable (can't use "ls", can't login, high load) o memberships broken (group resolution problems) o permissions problems (group resolution problems) o server stops responding o broken Winbind caches o server unbinding unexpectedly o DCs not responding in a timely fashion o Trusts just don't work at all as far as I can tell And whatever you do, don't ever try to login to the server with a username that doesn't exist. If you do, the server will become unusable for an extended period of time while it queries each and every object in the domain and any references the domain offers until there aren't any left to query. It will wait for all of the failed referrals to time out before it moves to the next non-existent object. You'll finally be able to use it again when the query returns, however. Finally, I have to say I don't recommend this to anyone. In my opinion, if you can't afford the commercial solution (Centrify), then just don't do it. You'll be much happier in the long run just creating users with secure passwords locally on the box, and requiring password changes. I can tell you for a fact that doing it that way will just work. Grant M. -- Grant Mongardi Senior Systems Engineer NAPC gmongardi-cGmSLFmkI3Y at public.gmane.org http://www.napc.com/ blog.napc.com 781.894.3114 phone 781.894.3997 fax NAPC | technology matters
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |