Changing domain for ntlm_auth
Hi all. To let (most (*)) users login with their e-mail address, I'd need to "translate" the realm part to a domain. So I added to proxy.conf : realm PERSONALE { } realm STUDENTI { } realm "~^studio\\.unibo\\.it" { Realm := "STUDENTI" } realm "~^studio\\.unibo\\.it" { Realm := "PERSONALE" } realm "~^unibo\\.it" { Realm := "PERSONALE" } What I thought it would do was "if user name is like '@studio.unibo.it' then set REALM to be local 'STUDENTI'" but obviously I was wrong... Request is EAP-PEAP-MSChapv2 and the authentication oracle is an AD node (hence the use of ntlm_auth). If I authenticate using user@PERSONALE it works perfectly. What am I missing? (*) Just 'most' users since I couldn't yet find a way to use the UPN, so users whose UPN have been changed must login with their 'base' name. Don't think there's an easy fix for this, since even joined win machines *sometimes* refuse the changed UPN... Tks, Diego.
NdK wrote:
To let (most (*)) users login with their e-mail address, I'd need to "translate" the realm part to a domain.
I'm not sure why.
So I added to proxy.conf : ... realm "~^studio\\.unibo\\.it" { Realm := "STUDENTI" }
Huh? NOTHING in the documentation or examples says that should work. It won't work. Don't do it.
What I thought it would do was "if user name is like '@studio.unibo.it' then set REALM to be local 'STUDENTI'" but obviously I was wrong...
The server documentation describes how it works. Follow the documentation to configure it.
Request is EAP-PEAP-MSChapv2 and the authentication oracle is an AD node (hence the use of ntlm_auth).
I'm not sure you can change the domain for PEAP with ntlm_auth. The domain is *also* in the MS-CHAP data. So changing it in the arguments to ntlm_auth will likely not work.
If I authenticate using user@PERSONALE it works perfectly. What am I missing?
It doesn't work the way you think it works. It works the way it's documented to work.
(*) Just 'most' users since I couldn't yet find a way to use the UPN, so users whose UPN have been changed must login with their 'base' name. Don't think there's an easy fix for this, since even joined win machines *sometimes* refuse the changed UPN...
Have the users change their login domain. Alan DeKok.
Il 25/01/2012 12:48, Alan DeKok ha scritto:
To let (most (*)) users login with their e-mail address, I'd need to "translate" the realm part to a domain. I'm not sure why. Because KRB5-domain and DNS-domain are different in my setup. And I can't change it.
So I added to proxy.conf : ... realm "~^studio\\.unibo\\.it" { Realm := "STUDENTI" } Huh? NOTHING in the documentation or examples says that should work. It won't work. Don't do it. Ok.
What I thought it would do was "if user name is like '@studio.unibo.it' then set REALM to be local 'STUDENTI'" but obviously I was wrong... The server documentation describes how it works. Follow the documentation to configure it. But what should I do? In other words, *which* doc should I follow? How is the needed feature named?
I'm not sure you can change the domain for PEAP with ntlm_auth. The domain is *also* in the MS-CHAP data. So changing it in the arguments to ntlm_auth will likely not work. I *think* it works by omitting the domain from checks, just like when considering NT domain...
If I authenticate using user@PERSONALE it works perfectly. What am I missing? It doesn't work the way you think it works. It works the way it's documented to work. I know. But I couldn't find the doc to read...
(*) Just 'most' users since I couldn't yet find a way to use the UPN, so users whose UPN have been changed must login with their 'base' name. Don't think there's an easy fix for this, since even joined win machines *sometimes* refuse the changed UPN... Have the users change their login domain. Those "pathologic" cases have to change. But it's usually much better to let 99% of the users authenticate in the same way on all the services...
BYtE, Diego.
On 01/25/2012 10:37 AM, NdK wrote:
Hi all.
To let (most (*)) users login with their e-mail address, I'd need to "translate" the realm part to a domain.
Why do you think this is true?
(*) Just 'most' users since I couldn't yet find a way to use the UPN, so users whose UPN have been changed must login with their 'base' name. Don't think there's an easy fix for this, since even joined win machines *sometimes* refuse the changed UPN...
I don't understand any of this. Please show a debug of it going wrong.
Il 25/01/2012 13:32, Phil Mayers ha scritto:
To let (most (*)) users login with their e-mail address, I'd need to "translate" the realm part to a domain. Why do you think this is true? 'cause ntlm_auth won't authenticate user.name@unibo.it or user.name@PERSONALE . It returns "no such user". It authenticates PERSONALE\user.name . Or "--username=user.name --domain=PERSONALE".
(*) Just 'most' users since I couldn't yet find a way to use the UPN, so users whose UPN have been changed must login with their 'base' name. Don't think there's an easy fix for this, since even joined win machines *sometimes* refuse the changed UPN... I don't understand any of this. Please show a debug of it going wrong. That's not FR-related. It's something in Win/AD, so I think there's nothing doable from FR to "fix" it.
BYtE, Diego.
Hi,
Il 25/01/2012 13:32, Phil Mayers ha scritto:
To let (most (*)) users login with their e-mail address, I'd need to "translate" the realm part to a domain. Why do you think this is true? 'cause ntlm_auth won't authenticate user.name@unibo.it or user.name@PERSONALE . It returns "no such user". It authenticates PERSONALE\user.name . Or "--username=user.name --domain=PERSONALE".
use Stripped-User-Name in the ntlm_auth line....and NT-Domain for domain (enable ntdomain in authorize) - see the example ntlm_auth provided with server... alan
Il 25/01/2012 15:58, Alan Buxey ha scritto:
use Stripped-User-Name in the ntlm_auth line....and NT-Domain for domain (enable ntdomain in authorize) - see the example ntlm_auth provided with server... Already tried and discarded. I think the definitive solution is the one highlighted by Phil.
Tks. Diego.
Hi,
Il 25/01/2012 15:58, Alan Buxey ha scritto:
use Stripped-User-Name in the ntlm_auth line....and NT-Domain for domain (enable ntdomain in authorize) - see the example ntlm_auth provided with server... Already tried and discarded. I think the definitive solution is the one highlighted by Phil.
umm, that solution is the same as i said. go read. alan
On 01/25/2012 02:30 PM, NdK wrote:
Il 25/01/2012 13:32, Phil Mayers ha scritto:
To let (most (*)) users login with their e-mail address, I'd need to "translate" the realm part to a domain. Why do you think this is true? 'cause ntlm_auth won't authenticate user.name@unibo.it or user.name@PERSONALE . It returns "no such user". It authenticates PERSONALE\user.name . Or "--username=user.name --domain=PERSONALE".
So don't pass that in.
That's not FR-related. It's something in Win/AD, so I think there's nothing doable from FR to "fix" it.
Not so. You can configure FreeRADIUS to pass correct data. There are many ways to do this. The "simplest" is something like follows: modules/mschap: ... ntlm_auth = ".. \ --username=%{%{Stripped-User-Name}:-%{mschap:User-Name}} \ --nt-domain=YOUR-DOMAIN" sites-enabled/whatever: authorize { ... ntdomain suffix mschap ... } ...and define the realms in your proxy.conf file. This solution basically uses the "realm" module to strip the DOMAIN\user and user@domain.com into "user" and "DOMAIN / domain.com". You then ignore the realm in your ntlm_auth line - just hard-code it. If you can't ignore the realm, you can do something like: modules/mschap: ... ntlm_auth = ".. \ --username=%{%{Stripped-User-Name}:-%{mschap:User-Name}} \ --nt-domain=%{%{Realm}:-DEFAULT}" sites-enabled/whatever: authorize { ... suffix ntdomain # check and maybe re-write the realm if (Realm) { switch "%{Realm}" { case "SHORT" { # nothing to do, leave along } case "LONG.FORM" { update request { Realm := "SHORT" } } case { # unknown realm reject } } } mschap } Alternatively you can process the realm yourself using regexps. This gives you a bit more control. For example: authorize { if (User-Name =~ /^SHORT\(.+)$/) { update request { Realm := SHORT Stripped-User-Name := "%{1}" } } elsif (User-Name =~ /^(.+)@long.com/i) { update request { Realm := SHORT Stripped-User-Name := "%{1}" } } ... } ...and so on. Basically, YOU control what data is passed to ntlm_auth, and FreeRADIUS provides several methods to control this. All you need to do is: 1. Write down a list of which formats you want to allow 2. Write a FreeRADIUS config that allows those formats, and passes the correct data into ntlm_auth If you need more specific help, just ask. But please try to read the docs for "man unlang" and the many, many examples in the default configs and in the list archives.
Il 25/01/2012 18:24, Phil Mayers ha scritto:
There are many ways to do this. The "simplest" is something like follows: modules/mschap: ... ntlm_auth = ".. \ --username=%{%{Stripped-User-Name}:-%{mschap:User-Name}} \ --nt-domain=YOUR-DOMAIN" That's not doable. If mail is in unibo.it, domain is not unibo.it but PERSONALE. Same if mail is in esterni.unibo.it . But for studio.unibo.it domain is STUDENTI.
sites-enabled/whatever: authorize { ... ntdomain suffix mschap ... } ...and define the realms in your proxy.conf file. That's what I was trying :)
This solution basically uses the "realm" module to strip the DOMAIN\user and user@domain.com into "user" and "DOMAIN / domain.com". You then ignore the realm in your ntlm_auth line - just hard-code it. Can't hardcode.
If you can't ignore the realm, you can do something like: modules/mschap: ... ntlm_auth = ".. \ --username=%{%{Stripped-User-Name}:-%{mschap:User-Name}} \ --nt-domain=%{%{Realm}:-DEFAULT}" More something like %{%{mschap:Domain}:-%{Realm}:-PERSONALE} ... [...] So I *can* insert unlang code there! Perfect!
Basically, YOU control what data is passed to ntlm_auth, and FreeRADIUS provides several methods to control this. It's enough to know where those controls can be placed :)
If you need more specific help, just ask. But please try to read the docs for "man unlang" and the many, many examples in the default configs and in the list archives. I tried (I always try for at least a couple hours before posting a question)... But without knowing what you're looking for it's hard to dig it...
Tks. I think w/ these infos I'll be OK. BYtE, Diego.
On 01/25/2012 07:21 PM, NdK wrote:
That's not doable. If mail is in unibo.it, domain is not unibo.it but PERSONALE. Same if mail is in esterni.unibo.it . But for studio.unibo.it domain is STUDENTI.
Ok, so you've got >1 AD domain. Not terribly common, but it ought to work with mapping as per the 2nd solution.
If you can't ignore the realm, you can do something like: modules/mschap: ... ntlm_auth = ".. \ --username=%{%{Stripped-User-Name}:-%{mschap:User-Name}} \ --nt-domain=%{%{Realm}:-DEFAULT}" More something like %{%{mschap:Domain}:-%{Realm}:-PERSONALE} ... [...] So I *can* insert unlang code there! Perfect!
No. This is not "unlang". It's just a string expansion. Unlang is a processing "language" that is only valid inside the virtual server "authorize", "post-auth", etc. sections. It's not valid in module configs. String expansions (which are valid in unlang) are valid most (not all) places. So: 1. Use "unlang" in authorize to set a string variable (e.g. Realm) 2. Use string expansions in the "ntlm_auth" config of the "mschap" module to access the string variable.
Il 25/01/2012 20:54, Phil Mayers ha scritto:
[...] So I *can* insert unlang code there! Perfect! No. This is not "unlang". It's just a string expansion. Yup. Sorry, I was referencing the cut part.
Unlang is a processing "language" that is only valid inside the virtual server "authorize", "post-auth", etc. sections. It's not valid in module configs. OK.
Since it seems I have to do EXACTLY the same mapping both in "default" and "inner-tunnel" sites, I saved my "if" chain in unibo.map and used $INCLUDE to insert it in both virtual servers, just after the opening brace of authorize. Hope it's the correct thing to do :) (even if there's a "suspect" preprocess module in 'default' thats smells like a candidate...). Too bad it seems unlang doesn't like : if (cond) { ... } elsif (othercond) { ... } elsif (yetanother) { ... } (gives "too many closing braces" on the last line) or even: if (cond) { ... } else if (othercond) { ... } else if (yetanother) { ... } (this one evaluates 'othercond' and 'yetanother' even if 'cond' is true, completely discarding the 'else'). [The ratio to use the 'if' on another line is that doing so I can reorder the conditions w/o introducing errors] That seems quite a serious limit in the unlang grammar... BYtE, Diego.
NdK wrote:
Too bad it seems unlang doesn't like : if (cond) { ... } elsif (othercond) {
Perhaps you could try reading "man unlang" to learn it's syntax.
That seems quite a serious limit in the unlang grammar...
Sure. It can't parse Perl, Python, Ruby, C, or any other invented grammar. The grammar it *can* parse is documented. It even gives examples. Even better, it *explains* why it's grammar is limited. Read the documentation. Alan DeKok.
Il 26/01/2012 10:40, Alan DeKok ha scritto:
NdK wrote:
Too bad it seems unlang doesn't like : if (cond) { ... } elsif (othercond) {
Perhaps you could try reading "man unlang" to learn it's syntax. Been confused by the error: it pointed to the last line of the chain, not to the *first* closing brace followed by a keyword, forming an invalid entry. BTW, it stays unclear why the keyword can't be on the same line with the closing brace. Can't figure out unlang's grammar in EBNF. Man page is somewhat contraddictory: first it says "The language consists of a series of entries, each one one line." but then allows multi-line entries calling 'em blocks...
But, reading again the man page, another doubt arises: in a chain, an else/elsif references to the "immediately preceding 'if' entry" or to the "last evaluated 'if' entry" (supposing elsif equivalent to "else\nif")? Being it read line-by-line it could easily be the first (static binding), but my test suggests the "common" behaviour (once one is true, all the following aren't evaluated). But I could be wrong... BYtE, Diego.
NdK wrote:
Been confused by the error: it pointed to the last line of the chain, not to the *first* closing brace followed by a keyword, forming an invalid entry. BTW, it stays unclear why the keyword can't be on the same line with the closing brace. Can't figure out unlang's grammar in EBNF.
It doesn't use ABNF.
Man page is somewhat contraddictory: first it says "The language consists of a series of entries, each one one line." but then allows multi-line entries calling 'em blocks...
And you conveniently deleted the NEXT sentence: Each entry begins with a keyword.
But, reading again the man page, another doubt arises: in a chain, an else/elsif references to the "immediately preceding 'if' entry" or to the "last evaluated 'if' entry" (supposing elsif equivalent to "else\nif")? Being it read line-by-line it could easily be the first (static binding), but my test suggests the "common" behaviour (once one is true, all the following aren't evaluated). But I could be wrong...
Then you don't understand how "if" and "else" work. It works the same way as Perl, C, and other languages. Alan DeKok.
On 01/26/2012 09:36 AM, NdK wrote:
Since it seems I have to do EXACTLY the same mapping both in "default" and "inner-tunnel" sites, I saved my "if" chain in unibo.map and used $INCLUDE to insert it in both virtual servers, just after the opening brace of authorize. Hope it's the correct thing to do :) (even if there's a "suspect" preprocess module in 'default' thats smells like a candidate...).
You can re-use bits of "unlang" as virtual modules. See "policy.conf". This is often a bit neater than $INCLUDE. I do exactly this, for exactly this case (username/realm processing).
Too bad it seems unlang doesn't like : if (cond) { ... } elsif (othercond) {
Well, no. FreeRADIUS config is basically: block { item item = value sub-block { subitem } sub-block2 { subitem2 } } "if", "elsif" are just blocks. Blocks need to start on their own line. The name is intended as a hint here - it's NOT a programming language. It's a syntax for writing authentication policies and rules, that is a bit like a language.
That seems quite a serious limit in the unlang grammar...
That's quite a statement. Can't you just hit "return" after "}"?
Il 26/01/2012 12:24, Phil Mayers ha scritto:
You can re-use bits of "unlang" as virtual modules. See "policy.conf". This is often a bit neater than $INCLUDE. Perfect! Exactly what was needed.
FreeRADIUS config is basically: [...] "if", "elsif" are just blocks. Blocks need to start on their own line.
The name is intended as a hint here - it's NOT a programming language. It's a syntax for writing authentication policies and rules, that is a bit like a language. Then maybe the second sentence (and following) in the second paragraph in the 'keywords' section of the man page could be more like: "unlang is a sequence (ordered list) of action blocks. Each action block, identified by a keyword, starts on its own line and can span multiple lines where a sub-block is allowed. Processing of a block is sequential, from the first line to the last."
This gives a pretty (quite regular) EBNF grammar... :)
That seems quite a serious limit in the unlang grammar... That's quite a statement. Can't you just hit "return" after "}"? Sure. That statement was due to a misunderstanding: that error made me think I couldn't chain more than one elsif !
BYtE, Diego.
participants (4)
-
Alan Buxey -
Alan DeKok -
NdK -
Phil Mayers