Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CentOS magic to Active Directory login?



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org