[rhelv6-list] winbind for logon when lost networking

Sun Feb 10 04:19:03 UTC 2013

On Sat, Feb 9, 2013 at 12:28 PM, Red Hat Enterprise Linux 6 (Santiago)
discussion mailing-list <rhelv6-list at redhat.com> wrote:
> Thank you for your in-depth answer.  The reference architecture doc looks
> quite thorough, and I may re-do this some time in the future.

I don't understand what you mean by "re-do"?  Maybe I should step
back.  I mentioned the doc because _every_ admin deploying RHEL6 who
must use AD _should_ read it.  Even if you end up only being able to
do #1, it is very, very educational.  It might even be helpful in
dealing with technology-ignorant AD admins.  ;)

Now with that said, I don't want to go down that rabbit hole, which
I'll leave to my "P.S."  Let's focus on your primary issue ... DNS
resolution.

> I don't have SSSD enabled,

I did some more digging and it's clear SSSD isn't going to help you
much here (until RHEL 6.4 and SSSD 1.9).  SSSD waits for DNS
resolution issues to figure out off-line mode.  I'm not sure Winbindd
does this or has similar logic.

However, Winbindd _does_ caching itself.  _And_ you could enable
dnsmasq on every system too.  The combination should do away with your
DNS query issues and Winbindd lookup problems.  And even if you switch
to SSSD 1.9 when RHEL 6.4 comes out, you'll still probably want
dnsmasq running if your network has so many issues with DNS and
connectivity.

BTW, you _could_ use SSSD to migrate logins to another store (e.g.,
LDAP), and put your UID, GID, homedir, etc... there instead.  That's
how most "enterprises" do it when AD's refuse to centralize POSIX
attributes in AD.  It usually becomes a "compliance" issue** at that
point, as the AD admins refuse to offer it.

> nor the possiblity at this time of implementing RFC2307.

I understand this.  The great majority of AD designs I've been exposed
to are very poorly designed, just for Windows.  And some of us have
even been involved with writing LDIF and other things for AD setups,
because the AD admins don't understand such things.  ;)

> The 6.3 deploment guide mentions:
> "SSSD works with LDAP identity providers (including OpenLDAP, Red Hat
> Directory Server, and Microsoft Active Directory) and can use native LDAP
> authentication or Kerberos authentication."

Yeah, SSSD (through 1.8) requires the POSIX attributes be installed
(IdM for UNIX) and populated.

> Do you have any notes or tips on caching SSD + Winbind?

Winbindd has its own caching.  But I think your bigger issue is DNS.
If DNS is unreliable, then that's a problem in itself.  SSSD 1.9 (RHEL
6.4) will help mitigate some issues, but I think your issues are
bigger and elsewhere.  In fact, is the AD group doing your DNS as
well?  ;)

-- bjs

**P.S.  Again, the doc assumes you have AD, and isn't trying to sell
you on another identity solution (e.g., RHDS, IdM-IPA, etc...).  The
doc outlines four (4) options, not all but most available through RHEL
6.3.  They are ...
1.  Samba Winbindd (idmap_rip)
2.  Samba Winbindd (idmap_ad) -- requires IdM for UNIX
3.  SSSD Kerberos+LDAP -- requires IdM for UNIX
4.  Kerberos+LDAP -- legacy (don't recommend it)

Now you said your AD does _not_ offer centralized POSIX attributes --
i.e., IdM for UNIX neither enabled nor populated.  The latter is
always good to point out, because AD admins are often wholly ignorant
that IETF/POSIX open standard systems cannot use Windows-only NTuser
attributes (e.g., SIDs, UNC home path, etc...).  ;)  So that leaves
you with just #1, as #2 and #3 require it, and #4 is a legacy approach
I would not recommend (difficult to manage).  I wish there was an
option for SSSD caching end-to-end, but that's not added until SSSD
1.9 (RHEL 6.4) when SSSD adds local re-mapping like Winbindd.

When you start talking 100% Microsoft supported IdM for UNIX, you get
"dumb stares" from AD admins because the don't even understand how
NTuser and Windows-only attributes work.  Ironically and to
Microsoft's credit, it attempts to offer an "open standard" solution
in AD so enterprises can centralize basic POSIX (UNIX/Linux)
attributes.  SSSD was not only designed to work with that, but cache
them, from Day 1.  Without them, one can't have centralized
authentication for Linux with AD (I've had this discussion too many
times**).  It's actually done locally by mapping at the individual
systems, non-centralized (such as via Winbindd, or SSSD 1.9).

Even more ironic, many organizations want to pay money (high,
per-system CAL license fees) for a proprietary, off-AD store, instead
of the "open standard" solution Microsoft provides.  So they put those
attributes in a store that can only be utilized by a proprietary
vendor's solution with its per-system CAL licensing.  Even funnier,
most of the time they end up just managing the same POSIX attributes
any way, the ones they were complaining "Linux shouldn't require" in
AD (the IdM for UNIX attributes).

In most cases, once I prove AD can _only_ do centralized management of
POSIX attributes by installing IdM for UNIX, I finally get it
installed.  A quick history lesson on how Windows and IETF/POSIX
differ (with Microsoft not using the latter for Windows) "educates"
most AD admins (aka "my fellow MCITP/MCSE/MCSAs" as I humor them).
Then they realize they aren't dong any "centralized management," and
relying on each individual system to locally re-map, which is often
out-of-compliance.  If the AD admins still refuse, then I have a
justification for management for standing up an LDAP server for this,
so it is finally centralized.  ;)

I still cannot believe how many AD admins say "AD is our corporate
standard" but then don't populate non-Windows attributes.  Once
someone like myself comes in and explains this to his "fellow
MCITP/MCSE/MCSA peers," this usually either gets them populating them,
or us using our own, centralized solution for attributes, even if AD
still provides Kerberos authentication.  And with SSSD, we can even
migrate authentication if we want as well.  ;)