New User and AD Question

[McNutt, Justin M.]

> McNutt, Justin M. wrote:
> > ntlm_auth --request-nt-key --username='dnps-caplap-4$' 
> --domain=col.missouri.edu --challenge=(pasted-from-debug) 
> --nt-response=(pasted-from-debug)
> > 
> > The result was:  NT_KEY: (long hex string)
> 
>   Exactly.  Now that you know what works, the only problem is creating a
> configuration in FreeRADIUS that *automatically* uses that style of
> username && domain.

Sure.  I had been assuming that it worked, but this does prove it, thus reducing the number of unknowns in the conversation.

Based on the other thread regarding the behavior of the mschap module, here's where things stand.

	- The User-Name variable is set to host/computer.ad.domain.edu, which is acceptable to ntlm_auth.  In my environment, "ad.domain" may vary and is not set same as the "NT domain" (or even close).
	- The mschap module wants to take "ad.domain.edu" and set the NT-Domain variable to "ad", which likely works in some environments, but not here.
	- The hard-coded domain name in the ntlm_auth command line works, but only for users/hosts in that domain (obviously).

So in the short term, I'd like to figure out a way to automatically match the DNS-style domain name based on the User-Name variable and update the NT-Domain variable so ntlm_auth will work for more cases.

Depending upon how this is implemented - what I'm about to say may not be necessary - I'd like to see a flag for the mschap module that choose between the "NT-style domain guessing" (which results in "col" in this case) and "DNS-style domain guessing" (which would take everything after the first dot as the domain.  I think that might result in a cleaner solution in the long term.

I think it should be a flag - set to the current "NT-style guessing as the default - to maintain backward compatibility an ease of removal in case it turns out to be a Very Bad Idea Indeed.

What do you think?

--J