Multi-domain AD and Users Who Aren't So Bright

[McNutt, Justin M.]

On 02/01/2012 09:57 PM, McNutt, Justin M. wrote:

Thoughts?  Opinions?  Better ways to accomplish any/all of this?

Briefly, there's probably not much you can do to improve this. If you
have such a complex domain environment, you're going to have to write
complex policies OR mandate your users always use the correct "DOM\user"
format.

We just finished a many-year span trying to get users to understand and use DOM\user.  They don't get it, at least not consistently.  A ridiculously large number of phone calls to our Help Desk demonstrate this, not to mention the "Login incorrect" messages from FR.  (I built all of my "fix it" stanzas based on actual failed login attempts by users.)

Couple of things you could do; use SQL to store the mappings rather than
hard-code; replace your script with a SQL lookup (use a bulk LDAP dump
to populate unqualified user -> domain mapping, nightly).

I guess in an ideal world, Samba would handle any username format that
windows itself would handle, and none of this would be necessary e.g.
ntlm_auth might output:

SamAccountName: user
NT-Domain: DOM
NT_KEY: foobar

...and FR could populate those.

Ideally, ntlm_auth would just take SamAccountName and NT_KEY and figure out the domain for itself (requiring an LDAP lookup, which is cached by winbind if you use wbinfo to do it).

But TBH I think (not sure here) you've crafted a solution that processes
usernames windows itself could not; basically you've coded site-specific
knowledge into your configs. This is, necessarily, site specific!

That's true.  At the login screen, Windows will accept DOM\user or user at ad.domain.com, but my solution also allows for DOM/user and users at valid.email.address and just "user", plus anything else I feel makes sense to a human, and thus deserves to be accepted by the computer.

tl;dr - from what I can see, that's about as good as you're going to get.

Thanks for the reply.  I think so too, for the moment.

I didn't give many details on what the GetDomain.pl script does.  At first, I had it set to use "wbinfo --all-domains" to get a list of all valid domains in the forest (weeding out a few things like "BUILTIN"), and then just iterate through each domain and see if "user" had a SID in that domain.  On the one hand, this was wasteful.  On the other hand, it was still pretty fast, required no password (aside from the Samba/LDAP configs, which aren't seen at the command line), and winbind cached the results, including the negative results.

That caching seemed like a really good idea to me.  Sadly, it failed miserably.

In practice, the "wbinfo" method caused... problems.  We aren't exactly sure what it broke, but the test FR server would stop authenticating altogether.  When winbind was restarted, it would complain "Cannot find KDC for this domain," which usually means it needs to be removed and re-joined to AD.  But even that didn't *quite* fix it.  After re-joining and waiting a few minutes, the problem would go away.  (Likely, there's some AD policy that was violated that temporarily locked the "resource" account that Samba and/or FR use for authenticating *themselves* to AD that had to expire.)

So wbinfo works from the command line by hand, not so much when scaled up.

So now GetDomain.pl uses "ldapsearch".  Advantage is it works well and only requires a single lookup per user ID (rather than iterating through anything).  Disadvantage is lack of any sort of caching (SQL server for cache might be good here), and the fact that I, personally, find that when I have to include the password in the CLI arguments and the program does not hide them for me in the "ps" output, I'm a bit disappointed.

So yeah, I'm pretty happy with it so far.  We'll see how it scales up when it's done to the production servers.  Setting up MySQL and a single table to hold user / domain / TTL cached data wouldn't be difficult, though the politics around here are such that I'll have to ask around a bit about the "best way to do that," even if the end result is the same.  *sigh*

(I can always build it on just the test server and call it a proof of concept, of course....)

--J