So I'm working on a way to Improve the User Experience. I've gotten a LONG way, but now I'm stuck. Here's the short/long version (all details, without undue explanation or discussion of what I tried that doesn't work): WARNING: This may well be a case of doing it the hard way. If that's the case, feel free to tell me, but it's not for lack of trying to research this via Google, searching archives of this list, etc. Just tell me what I'm doing wrong. I can handle it. ;) Okay, here goes: 1) I created two custom attributes named "My-NT-Domain" and "My-User-Name" and added them to the dictionary file as 3003 and 3004, respectively. 2) I added sections to sites-enabled/my-virt-server in the "authorize {" like this: # Allow host-based authentication for computers in the domain. if ( User-Name =~ /host\/[^\.]+\.(.+)/ ) { update request { My-User-Name = "%{mschap:User-Name}" My-NT-Domain = "%{1}" } } # Fix the forward slash. elsif ( User-Name =~ /([^\/]+)\/(.+)/ ) { update request { My-User-Name = "%{2}" My-NT-Domain = "%{1}" } } # New student e-mail format. elsif ( User-Name =~ /([^@]+)@mail.missouri.edu/ ) { update request { My-User-Name = "%{1}" My-NT-Domain = "TIGERS" } } ... and so on. 3) I changed /etc/raddb/modules/mschap to call ntlm_auth like this: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{My-User-Name}:-%{mschap:User-Name}} --domain=%{%{My-NT-Domain}:-%{mschap:NT-Domain}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" So at this point, if a user plugs in the correct "domain\username" stuff, none of the "cleanup" cases match, so my custom attributes are empty, and the usual %{mschap:xx} variables work fine. If fixes were necessary, the custom attributes take over. All that works fine. NOW we want to be able to have a user authenticate without specifying a domain. In theory, that's no big deal. If the users NEVER specify a domain at all, I can populate my custom attributes with this: if ( ! My-NT-Domain ) { update request { My-User-Name = "%{User-Name}" My-NT-Domain = `/etc/raddb/bin/GetDomain.pl %{User-Name}` } } The "GetDomain.pl" script does a command-line LDAP search (using "ldapsearch") against our AD for %{User-Name}, grabs the dn attribute, matches the AD domain, and returns the NT domain that corresponds. This also works. NOW, the problem is that if the user DOES specify "domain\username" correctly, then none of the "cleanup" cases match, so My-NT-Domain is empty. But since my custom attribute is empty, the Perl script is being called unnecessarily to run the LDAP search. Solution: I was still thinking about this as I wrote it, and I modified the "final check" clause (that looks for the total absence of domain hints) and I thought of a way to implicitly resolve the case where the user passes scary characters in the user ID (injection attack) AND the case where the user specified a valid domain\username set of creds at the same time: # Check special fix-it cases above. # These could probably be done as a single if statement. # It was simpler to keep them separate while testing. if ( ! My-NT-Domain ) { if ( User-Name =~ /^[a-zA-Z0-9]+$/ ) { update request { My-User-Name = "%{User-Name}" My-NT-Domain = `/etc/raddb/bin/GetDomain.pl %{User-Name}` } } } This appears to be working. Overall, I give this solution about a B+. PROS: Works in a single forest, multi-domain environment, regardless of any conformity to typical AD domain naming standards. Makes authentication SIMPLE for the users. The way I wrote the GetDomain script, it always returns DOMAIN or (null) after only a single LDAP query (efficient). Combined with judicious use of "radiusd -XC" provides a simple way to correct common typos. Permits computer-based authentication to work again in multi-domain or non-typical-naming cases (where mschap currently fails). Still reports the original creds as given by user (in case you still want to report on the cases that needed fixing and resolve the problem at the source, rather than making FR do all the work. Limited to this virtual server. CONS: In many cases - like translating "col.missouri.edu" to "UMC-USERS", the "fixes" are hard-coded. By comparison, changing the / to a \ works for any domain in a single check. Doubles (at least) the number of calls to AD in cases where everyone is lazy and leaves out the domain. I.e. an LDAP call to get the domain plus the authentication itself. Encourages user ignorance. (Judgement call.) Limited to this virtual server. Thoughts? Opinions? Better ways to accomplish any/all of this? --J
Btw, kudos to Alan DeKok and the rest of the FR developers for these FR abilities. The things listed here were INVALUABLE to figuring all of this out without just guessing: 1) "radiusd -XC" You just can't live without this. Seriously. 2) "radiusd -X" It's there for a reason. Specifically, 3) THIS (from radiusd -X): ++? if (User-Name =~ /host\/[^\.]+\.(.+)/ ) ? Evaluating (User-Name =~ /host\/[^\.]+\.(.+)/) -> FALSE ++? if (User-Name =~ /host\/[^\.]+\.(.+)/ ) -> FALSE ++? elsif (User-Name =~ /([^\/]+)\/(.+)/ ) ? Evaluating (User-Name =~ /([^\/]+)\/(.+)/) -> FALSE ++? elsif (User-Name =~ /([^\/]+)\/(.+)/ ) -> FALSE 4) and THIS: [mschap] Told to do MS-CHAPv2 for tmpid with NT-Password [mschap] expand: %{My-User-Name} -> [mschap] expand: %{mschap:User-Name} -> tmpid [mschap] expand: --username=%{%{My-User-Name}:-%{mschap:User-Name}} -> --username=tmpid [mschap] expand: %{My-NT-Domain} -> [mschap] expand: %{mschap:NT-Domain} -> testing [mschap] expand: --domain=%{%{My-NT-Domain}:-%{mschap:NT-Domain}} -> --domain=testing 5) and last, but certainly not least, "man unlang". It won't read itself, yanno! It may not be the best way to do it, but it works, and I couldn't have done it without all of these debugging features. It's what my Linux sysadmin calls "awesome sauce." --J From: Z <mcnuttj@missouri.edu<mailto:mcnuttj@missouri.edu>> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Date: Wed, 1 Feb 2012 21:57:02 +0000 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Multi-domain AD and Users Who Aren't So Bright So I'm working on a way to Improve the User Experience. I've gotten a LONG way, but now I'm stuck. Here's the short/long version (all details, without undue explanation or discussion of what I tried that doesn't work): WARNING: This may well be a case of doing it the hard way. If that's the case, feel free to tell me, but it's not for lack of trying to research this via Google, searching archives of this list, etc. Just tell me what I'm doing wrong. I can handle it. ;) Okay, here goes:
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. 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. 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! tl;dr - from what I can see, that's about as good as you're going to get.
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@ad.domain.com, but my solution also allows for DOM/user and users@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
On 02/02/2012 12:35 PM, McNutt, Justin M. wrote:
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
Not unreasonably. It's a failure of the IT Industry to solve credentials. Most attention gets paid to passwords, but usernames matter too - the vast majority of users have difficulty distinguishing between username and email address, and they're not interchangeable (because the string is mixed into the challenge/response algorithms).
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.)
The other "option" is a single-domain environment. I've no idea of the size of your site, but we do this. It removes a lot of hassle. Obviously, that's probably not a sensible option for you; the disruption of a move would be enormous!
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.)
Yeah, we've seen similar things. It's a real shame the user/group database stuff in winbind isn't reliable. We've also seen winbind drop out of the domain for no readily apparent reason. Winbind is also REALLY bad at detecting domain controller failure; it keeps the TCP connection to the chosen DC open, and can take 30 seconds or more to detect failures, and only *then* performs DC re-discovery. Sigh... Unfortunately, I don't have the time to chase the underlying problems and report them to the Samba guys.
From: Phil Mayers <p.mayers@imperial.ac.uk<mailto:p.mayers@imperial.ac.uk>> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Date: Thu, 2 Feb 2012 14:09:30 +0000 To: <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Re: Multi-domain AD and Users Who Aren't So Bright On 02/02/2012 12:35 PM, McNutt, Justin M. wrote: 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.) The other "option" is a single-domain environment. I've no idea of the size of your site, but we do this. It removes a lot of hassle. Obviously, that's probably not a sensible option for you; the disruption of a move would be enormous! We looked at this. A lot. For these specific reasons. The main problems are political. TECHNICALLY, we could just build a new domain in the existing forest and put everything NEW into that domain, then allow all of the other domains (except two) fade out through attrition. The two exceptions would be the forest root (which contains no user or computer accounts), and a special domain that contains only retired user accounts (long story) and thus, not my problem. But we won't do that, because this is a multi-campus university with lots of autonomy issues and wrangling for independence. So we'll have to "fight the good fight" and make any software we use work in a multi-domain environment as AD was intended to work, regardless of any other practical issues. ;) We've also seen winbind drop out of the domain for no readily apparent reason. Winbind is also REALLY bad at detecting domain controller failure; it keeps the TCP connection to the chosen DC open, and can take 30 seconds or more to detect failures, and only *then* performs DC re-discovery. Sigh... Unfortunately, I don't have the time to chase the underlying problems and report them to the Samba guys. Same here on all counts, though we don't have machines dropping out very often. But these kinds of things are why we have some complicated load balancing and redundancy in front of the RADIUS servers. It's not a failure of FreeRADIUS, but rather the imperfect world that FR lives in. Plus, in addition to reading through these replies and refining my multi-domain user-ID-fixing implementation, my current FR effort is to make the config more robust and tolerant of server failures. The ldap module is currently configured in a way that depends entirely upon a single domain controller. That's bad. I KNOW there's a way to config FR better than this. I just have to go read more stuff in /usr/share/docs/freeradius. --J
Il 02/02/2012 13:35, McNutt, Justin M. ha scritto:
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. Or make 'em use their institutional email address. Easier to remember :) Seems trivial but it might not be. At least in our case we have 3 kinds of email addresses, referring to 2 domains. And the name before the '@' sign might not be the same as the sAMAccountName.
I'm trying (with no luck :( ) to use /usr/bin/net ads search -P "(mail=%{User-Name})" sAMAccountName|grep sAMAccountName|sed "s/^[^ ]* //" (maybe it's possible to do the same without using grep and sed, but it's been just a quick test -- suggestions welcome). Replacement is OK, but seems secrets.tdb can't be opened :( even if permissions should be OK :-? A limit of net ads search is that it searches only the default (joined) domain, unless you specify another domain controller with -S or -I -- I could easily do that based on the mail domain but in others setups it could be harder. BYtE, Diego.
On Thu, Feb 02, 2012 at 06:33:19PM +0100, NdK wrote:
I'm trying (with no luck :( ) to use /usr/bin/net ads search -P "(mail=%{User-Name})" sAMAccountName|grep sAMAccountName|sed "s/^[^ ]* //" (maybe it's possible to do the same without using grep and sed, but it's been just a quick test -- suggestions welcome).
Have you tried ldapsearch? Might be more flexible.
A limit of net ads search is that it searches only the default (joined) domain, unless you specify another domain controller with -S or -I -- I could easily do that based on the mail domain but in others setups it could be harder.
I'm rather guessing here, but I wonder if LDAP searching the AD global catalogue (ports 3268/3269) would make this work with one search? But that's not really a FreeRADIUS issue. You'd probably be better finding a samba or AD list. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Il 02/02/2012 21:59, Matthew Newton ha scritto:
>> /usr/bin/net ads search -P "(mail=%{User-Name})" sAMAccountName|grep
>> sAMAccountName|sed "s/^[^ ]* //"
>> (maybe it's possible to do the same without using grep and sed, but it's
>> been just a quick test -- suggestions welcome).
>
> Have you tried ldapsearch? Might be more flexible.
Can't use it: for security (privacy) our DCs don't allow anonymous
binding. And I can't add users, just machines and OUs.
> I'm rather guessing here, but I wonder if LDAP searching the AD
> global catalogue (ports 3268/3269) would make this work with one
> search?
Often you can't do an ldap search on AD...
> But that's not really a FreeRADIUS issue. You'd probably be better
> finding a samba or AD list.
What I was saying was:
1) it should be doable to let users do MSCHAPv2 auth using mail account
(which could be unrelated to sAMAccountName) instead of "strange" (from
users' POV) usernames with domains
2) I was asking for some "trick" that lets me do the same thing without
requiring processes for grep and sed (if possible... and that's FR specific)
BYtE,
Diego.
Hi,
On Fri, Feb 03, 2012 at 08:22:38AM +0100, NdK wrote:
> Il 02/02/2012 21:59, Matthew Newton ha scritto:
>
> >> /usr/bin/net ads search -P "(mail=%{User-Name})" sAMAccountName|grep
> >> sAMAccountName|sed "s/^[^ ]* //"
> >> (maybe it's possible to do the same without using grep and sed, but it's
> >> been just a quick test -- suggestions welcome).
> >
> > Have you tried ldapsearch? Might be more flexible.
> Can't use it: for security (privacy) our DCs don't allow anonymous
> binding. And I can't add users, just machines and OUs.
ldapsearch allows you to bind as a specific user for searches
(I do that), but if you can't add users to your DCs (?!) then
I guess that option's out.
> > But that's not really a FreeRADIUS issue. You'd probably be better
> > finding a samba or AD list.
> What I was saying was:
> 1) it should be doable to let users do MSCHAPv2 auth using mail account
> (which could be unrelated to sAMAccountName) instead of "strange" (from
> users' POV) usernames with domains
> 2) I was asking for some "trick" that lets me do the same thing without
> requiring processes for grep and sed (if possible... and that's FR specific)
Apologies - I meant that finding the answer to your 'trick' is not
a FreeRADIUS thing. It's a directory lookup, or identity
management type issue.
Then, yes, of course it translates into 'how do I do this search
_within_ FreeRADIUS'.
Hence you might initially get better answers from AD people on the
lookup, rather than FreeRADIUS prople.
Cheers,
Matthew
--
Matthew Newton, Ph.D. <mcn4@le.ac.uk>
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Il 03/02/2012 12:51, Matthew Newton ha scritto:
Apologies - I meant that finding the answer to your 'trick' is not a FreeRADIUS thing. It's a directory lookup, or identity management type issue. There must be a misunderstanding. I'm not asking advice about the query itself (that would be OT here). *Given* that the query should (and that 'should' is not FR-related) return a 4-rows answer that I must translate to a single row, how do I translate it to a single value in FR? Currently I'm doing that translation spawning two more processes, that might not be needed. Can unlang regexprs handle multiline output or are they "limited" to single-line? Since this 'optimization' is FR-specific, I'm asking to FR gurus here...
Then, yes, of course it translates into 'how do I do this search _within_ FreeRADIUS'. I know that: backticks :)
BYtE, Diego.
On 02/03/2012 04:56 PM, NdK wrote:
There must be a misunderstanding. I'm not asking advice about the query itself (that would be OT here).*Given* that the query should (and that 'should' is not FR-related) return a 4-rows answer that I must translate to a single row, how do I translate it to a single value in FR? Currently I'm doing that translation spawning two more processes, that might not be needed.
Munge the output into one line, using a separator character that won't ever be in your input: foo~bar~baz ...then use a regexp: update request { Tmp-String-0 = "%{exec:...} } if (Tmp-String-0 =~ /^(.+)~(.+)~(.+)$/) { update request { My-Foo = "%{1}" My-Bar = "%{1}" My-Baz = "%{1}" } }
On 02/02/2012 05:33 PM, NdK wrote:
Il 02/02/2012 13:35, McNutt, Justin M. ha scritto:
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. Or make 'em use their institutional email address. Easier to remember :)
This doesn't work, unless username == email local part.
Seems trivial but it might not be. At least in our case we have 3 kinds of email addresses, referring to 2 domains. And the name before the '@' sign might not be the same as the sAMAccountName.
Exactly. And this name is mixed into the challenge/response. If you try to use email addresses, the client will calculate: response = crypto(challenge, e.mail@domain.com, password) Let's assume you map email -> username on your radius servers: Real-Username = some_lookup(User-Name) ...and you then call ntlm_auth, this basically asks the domain controllers: is_valid(Real-Username, challenge, response) The domain controllers do this: expected_response = crypto(challenge, samaccountname, stored_password) if response != expected_response: error else success See the problem? The domain controller performs its crypto calculation on the samaccountname. The client performs its crypto on the email addresses. The results differ, and authentication fails. Basically, usernames != email address, unless you MAKE them the same.
Il 03/02/2012 13:48, Phil Mayers ha scritto:
This doesn't work, unless username == email local part. *or* win uses the username to calculate the response. Since users *can* actually log in to their accounts using their mail address... Maybe win caches (or looks up) the real username?
Exactly. And this name is mixed into the challenge/response. If you try to use email addresses, the client will calculate: Just like the domain that 'ntdomain' strips. Or the others form of domain I'm already stripping.
expected_response = crypto(challenge, samaccountname, stored_password) Maybe they also calculate an alternative_response considering one (or more) alternate username forms. Or, simply, win looks up real username and domain when an email address is used and uses it to calculate its response.
Basically, usernames != email address, unless you MAKE them the same. We often have user accounts in the form user.name.2 referring a different person than user.name. The number-accounted person might not like the number, so asks for an UPN change and is given u.name. When another account is created (say that from Ph.D he becomes a researcher) the 'base name' would be user.name3, but the old UPN gets set for user.name2 and u.name now "points" to user.name3 . So the mail address is 'constant' even if the 'internal identity' changes. That person keeps logging in as u.name@unibo.it . Maybe that's a stupid thing, but it's how things work here and I have no control on that. I can only try to keep the best possible user experience.
BYtE, Diego.
On 02/03/2012 05:23 PM, NdK wrote:
*or* win uses the username to calculate the response. Since users *can* actually log in to their accounts using their mail address... Maybe win caches (or looks up) the real username?
Sure. If the client uses the "right" values as input to the crypto hash, then it will work. Obviously it has to be able to "know" the right values, so this only works on domain members.
Exactly. And this name is mixed into the challenge/response. If you try to use email addresses, the client will calculate:
Just like the domain that 'ntdomain' strips. Or the others form of domain I'm already stripping.
Not quite. The MSCHAP spec says you must strip leading DOMAIN\ before performing the crypto. Microsoft clients also strip trailing @domain.com, which makes sense. So, a "compliant" client and server will not include domains. FreeRADIUS is a bit complex in this area, because of the age of the code involved. But basically: 1. "with_ntdomain_hack = yes" on the mschap module strips leading DOMAIN\ 2. Otherwise, you have to populate Stripped-User-Name yourself Really, with_ntdomain_hack should be renamed "strip_domain", should strip either leading DOMAIN\ or trailing @domain.com, and should default to "on". I need to write a patch for 3.0 which does this.
expected_response = crypto(challenge, samaccountname, stored_password) Maybe they also calculate an alternative_response considering one (or
Maybe.
more) alternate username forms. Or, simply, win looks up real username and domain when an email address is used and uses it to calculate its response.
Possibly.
the 'base name' would be user.name3, but the old UPN gets set for user.name2 and u.name now "points" to user.name3 . So the mail address is 'constant' even if the 'internal identity' changes. That person keeps logging in as u.name@unibo.it .
That sounds complicated. We login with our SamAccountName. We don't login with our email address, and we don't login with some kind of AD mapping.
Maybe that's a stupid thing, but it's how things work here and I have no control on that. I can only try to keep the best possible user experience.
Maybe. I think you're doing something complicated and weird, and I don't think you should be surprised if it doesn't work well in some cases. I don't think userPrincipalName is meant to be used that way. But if it works for you, hey, go for it.
Il 03/02/2012 18:57, Phil Mayers ha scritto:
FreeRADIUS is a bit complex in this area, because of the age of the code involved. But basically: 1. "with_ntdomain_hack = yes" on the mschap module strips leading DOMAIN\ So it's not an "hack". It's "follow_mschap_specs" :)
2. Otherwise, you have to populate Stripped-User-Name yourself That's what I'm currently doing. Being the phylosophy "build by little steps", all the "domain logins" already work. Even "login with mail" for users w/o UPN change works. It could even be enough, but my hacking genes would be really upset if I didn't try everything... :)
Really, with_ntdomain_hack should be renamed "strip_domain", should strip either leading DOMAIN\ or trailing @domain.com, and should default to "on". Shouldn't that be handled by 'suffix' ?
I need to write a patch for 3.0 which does this. Good.
the 'base name' would be user.name3, but the old UPN gets set for user.name2 and u.name now "points" to user.name3 . So the mail address is 'constant' even if the 'internal identity' changes. That person keeps logging in as u.name@unibo.it . That sounds complicated. It is. Historical reasons ('we' started usin AD ages ago... even M$ techs gave up on our setup :) ). The same for having multiple domains: even M$ (at that time) didn't know if a single domain could handle about 500K users. *Now* we all know it can, and it's about 6 years a team is working to try to "collapse" the forest in a single tree.
Maybe. I think you're doing something complicated and weird, and I don't think you should be surprised if it doesn't work well in some cases. I don't think userPrincipalName is meant to be used that way. Neither do I, but others thought so and now it can't be changed (at least not easily, and for sure not by me)... If it won't work, I'll be confident it's impossible to make it work within our environment. But if I make it work, it could be useful for others.
BYtE, Diego.
I'm not sure why, then, but it actually does work. We have shown that with the client configured to use "user@e.mail.address" (where e.mail.address is NOT the same as the AD domain), if I have FR look for 'e.mail.address' and translate it to the correct NT domain, authentication succeeds. The user name must not be part of the crypto calculation or it would fail. I've been able to "correct" all kinds of things in the user name and set the domain manually to whatever I want. As long as I supply the correct password on the client side to what I happen to know the RADIUS server has mapped my ID to, authentication is successful. --J From: Phil Mayers <p.mayers@imperial.ac.uk<mailto:p.mayers@imperial.ac.uk>> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Date: Fri, 3 Feb 2012 12:48:30 +0000 To: <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Re: Multi-domain AD and Users Who Aren't So Bright On 02/02/2012 05:33 PM, NdK wrote: Il 02/02/2012 13:35, McNutt, Justin M. ha scritto: 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. Or make 'em use their institutional email address. Easier to remember :) This doesn't work, unless username == email local part. Seems trivial but it might not be. At least in our case we have 3 kinds of email addresses, referring to 2 domains. And the name before the '@' sign might not be the same as the sAMAccountName. Exactly. And this name is mixed into the challenge/response. If you try to use email addresses, the client will calculate: response = crypto(challenge, e.mail@domain.com<mailto:e.mail@domain.com>, password) Let's assume you map email -> username on your radius servers: Real-Username = some_lookup(User-Name) ...and you then call ntlm_auth, this basically asks the domain controllers: is_valid(Real-Username, challenge, response) The domain controllers do this: expected_response = crypto(challenge, samaccountname, stored_password) if response != expected_response: error else success See the problem? The domain controller performs its crypto calculation on the samaccountname. The client performs its crypto on the email addresses. The results differ, and authentication fails. Basically, usernames != email address, unless you MAKE them the same. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Il 12/02/2012 23:54, McNutt, Justin M. ha scritto:
I'm not sure why, then, but it actually does work. We have shown that with the client configured to use "user@e.mail.address" (where e.mail.address is NOT the same as the AD domain), if I have FR look for 'e.mail.address' and translate it to the correct NT domain, authentication succeeds. See Phil's answer on Feb 03 18:57 ... That's because domains (both NT-like and Kerberos-like) get stripped from crypto ops. Too bad you can't change user name when calling ntlm_auth (that's what I'd have to do for users with an UPN change).
The user name must not be part of the crypto calculation or it would fail. I've been able to "correct" all kinds of things in the user name and set the domain manually to whatever I want. As long as I supply the correct password on the client side to what I happen to know the RADIUS server has mapped my ID to, authentication is successful. The 'user' *is* part of the crypto. '@e.mail.address' (or 'DOMAIN\') is not.
BYtE, Diego.
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. Or make 'em use their institutional email address. Easier to remember :) Seems trivial but it might not be. At least in our case we have 3 kinds of email addresses, referring to 2 domains. And the name before the '@' sign might not be the same as the sAMAccountName. I'm trying (with no luck :( ) to use /usr/bin/net ads search -P "(mail=%{User-Name})" sAMAccountName|grep sAMAccountName|sed "s/^[^ ]* //" (maybe it's possible to do the same without using grep and sed, but it's been just a quick test -- suggestions welcome). Replacement is OK, but seems secrets.tdb can't be opened :( even if permissions should be OK :-? A limit of net ads search is that it searches only the default (joined) domain, unless you specify another domain controller with -S or -I -- I could easily do that based on the mail domain but in others setups it could be harder. A problem I'm having with that is the fact that we outsourced student e-mail (so they can continue to use that account after they graduate). So the password for their e-mail account is not the same as the password for their AD account (possibly). For the lookup, I'm betting that ldapsearch could be given a filter like (|(sAMAccountName=%{User-Name})(exchangeSMTPAliases=%{User-Name})) that would match any valid SMTP alias, but that's assuming that you're using Exchange and all of the aliases are visible in AD someplace. Also, I'm finding that the callouts to scripts of any kind to run 'ldapsearch' are fairly slow. I'm working on a way to run 'ldapsearch' daily and pre-populating an Oracle or MySQL database with the data that I want so that FR can look there first, and only go to an 'ldapsearch' script if that fails (maybe). I'm pretty impressed with the way ldapsearch will failover to a second, third, fourth URI given at the command line, but the shell call takes a lot of time as the load ramps up. --J
Il 01/02/2012 22:57, McNutt, Justin M. ha scritto:
So I'm working on a way to Improve the User Experience. I've gotten a LONG way, but now I'm stuck. Here's the short/long version (all details, without undue explanation or discussion of what I tried that doesn't work): Done nearly the same just some days ago.
1) I created two custom attributes named "My-NT-Domain" and "My-User-Name" and added them to the dictionary file as 3003 and 3004, respectively. I have had no need to create those. Just added, in policy.conf: unibo_map_realms { if (User-Name =~ /^(PERSONALE|STUDENTI)(\\.DIR\\.UNIBO\\.IT)?\(.+)$/i ) { update request { Realm := "%{1}" Stripped-User-Name := "%{3}" } } elsif (User-Name =~ /^(.+)@(PERSONALE|STUDENTI)(\\.DIR\\.UNIBO\\.IT)?$/i ) { [... and so on for the various forms...] Then added to proxy.conf: # LOCAL domains: *unibo.it realm "~^(.*\\.)?unibo\\.it" { } to handle "mail-like" domains locally and finally added to default and inner-tunnel a call to unibo_map_realms at the very beginning of authorize section.
3) I changed /etc/raddb/modules/mschap to call ntlm_auth like this: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{My-User-Name}:-%{mschap:User-Name}} --domain=%{%{My-NT-Domain}:-%{mschap:NT-Domain}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" No extra attributes needed in my case.
NOW we want to be able to have a user authenticate without specifying a domain. In theory, that's no big deal. If the users NEVER specify a domain at all, I can populate my custom attributes with this: [...] NOW, the problem is that if the user DOES specify "domain\username" correctly, then none of the "cleanup" cases match, so My-NT-Domain is empty. But since my custom attribute is empty, the Perl script is being called unnecessarily to run the LDAP search. What about checking both your attribute and the mschap:NT-Domain just after 'suffix' and 'ntdomain' entries?
BTW, do you see win setting a domain when the "use login credentials" checkbox (for mschapv2 options) is set? I always only see just the username... That might be good for your script... BYtE, Diego.
participants (4)
-
Matthew Newton -
McNutt, Justin M. -
NdK -
Phil Mayers