Dave Mussulman wrote:
passwords for local accounts. I'd like to change from maintaining my
own sql copy/user database to RADIUS proxying to someone else's server.
What's the recommended way to configure failover proxying/realms when
there's no realm-ish identifier? When "user" logs in, I want them to
check against ntlm_auth, and if that fails, resort back to a proxied
realm as "user". Right now, I'm doing that via the default config realm
Hmm. Do you have a list of the usernames which are local versus the ones
that are not? If so, I'd so:
authorize {
preprocess
themodule
files
Autz-Type LOCALAD {
mschap
}
}
"themodule" (be it a files, SQL or rlm_passwd instance) should set a
group on the to-be-proxied users e.g. REMOTE, and then the files module
should say:
DEFAULT My-Group == "REMOTE", Proxy-To-Realm := TheRealm
DEFAULT Autz-Type := LOCALAD
...then configure TheRealm appropriately. You can invert the sense if
you want to put the group on the local AD users.
suffix {} module, and a realm NULL section in proxy.conf. Is there a
better way? Hints or something? Does this involve the
configurable_failover documentation?
I don't think so - the mschap module will match during authorize if the
request has the mschap attributes. It won't run "halfway" to see if the
user is in AD, then run the "rest" of the way during authenticate to
actually auth them. So mschap will always match
Second question involves proxies and EAP. Since my upstream RADIUS
server I'm proxying to doesn't seem to support EAP, is it even possible
for my RADIUS server (in its PEAP/MSCHAPv2 decoding,) to create a
'normal' RADIUS packet to relay? Or do I have to get the upstream
server to support EAP? It seems like if suffix (realm) module is
anywhere in the authorize section, it proxies the entire EAP packet.
Can I tell it only to do that at a certain stage in the process?
The MS-CHAPv2 request from inside the PEAP goes through the server a 2nd
time, and you just need to configure the server to match that. Something
like:
authorize {
preprocess
eap
files
Autz-Type EAPINNER {
redundant {
user2realm
mschap
}
}
}
files' "users" needs to read:
DEFAULT NAS-IP-Address == 127.0.0.1, Autz-Type := EAPINNER
user2realm needs to be an rlm_passwd instance like so:
passwd user2realm {
filename = user2realm
format = "*User-Name:Proxy-To-Realm"
hashsize = 100
}
...and the contents of the file read:
username:TheRemoteRealm
user2:TheRemoteRealm
So processing goes:
1. preprocess
2. files - if from local, set autz-type
3. if autz-type==EAPINNER:
3a. call user2realm
3b. if "notfound" or "failed" call mschap
Both of the above techniques assume you have a list of the remote users.
If you don't, you could obtain a list of local users either statically
or dynamically via LDAP against AD and invert the sense of the matching.
If you can't do either, you may be out of luck
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
