> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
