On 6.1.2022 17.37, Ullfig, Roberto Alfredo wrote:
We are now using UsernameMatchesWithoutRealm whereas before we required
the domain not be included.
<Handler ConvertedFromEAPMSCHAPV2=1>
...
<AuthBy NTLM>
UsernameMatchesWithoutRealm
DefaultDomain AD
</AuthBy>
But I believe this will strip remote domains as well - so someone could
enter a remote domain and it would still work (as long as they have an
account locally of course).
Yes, I think that would happen. It would look odd in the logs, but would
require a valid local account for which the user knows the credentials,
as you wrote.
Would adding a new handler above like the
following fix this?
<Handler ConvertedFromEAPMSCHAPV2=1 Realm=/^(?:.+\.)*uic\.edu$/i>
Syntax: Add a comma and a minor regexp update to match absolute line end:
<Handler ConvertedFromEAPMSCHAPV2=1, Realm=/^(?:.+\.)*uic\.edu\z/i>
...
<AuthBy NTLM>
UsernameMatchesWithoutRealm
DefaultDomain AD
</AuthBy>
We want to allow both username and [email protected] - but not accept
something like [email protected].
I'd say the regexp wouldn't match realmless username, but something like
this should do it. See and try with the tester below:
Simplified version (it drops ?:): ^(|(.+\.)*uic\.edu)\z
#!/usr/bin/env perl
use strict;
use warnings;
# match empty, 'something.uic.edu' and 'uic.edu'
print "match\n" if ($ARGV[0] =~ m/^(?:|(?:.+\.)*uic\.edu)\z/i);
I strongly recommended following the realms with this additional Handler
that grounds the rest of the converted requests:
<Handler ConvertedConvertedFromEAPMSCHAPV2=1>
<AuthBy INTERNAL>
DefaultResult REJECT
</Handler>
</Handler>
This makes sure that realms such as 'example.com' get processed and
rejected.
Related to this: If there are also multiple <Handler TunnelledByPEAP=1,
...> instances, in this case there should be similar catch-all handler:
<Handler TunnelledByPEAP=1>
<AuthBy FILE>
EAPType ...
Filename /dev/null
</AuthBy>
<Handler>
This makes sure that EAP gets started when username and realm is not
known yet (the first EAP message) but it will never allows
authenticating PEAP tunnelled requests the other Handlers haven't matched.
To summarise how handle all converted and tunnelled requests:
<Handler ConvertedFromEAPMSCHAPV2=1, Realm=something>
# Authenticate something
</Handler>
<Handler ConvertedFromEAPMSCHAPV2=1, Realm=somethingelse>
# Authenticate somethingelse
</Handler>
# Unexpected realm: reject
<Handler ConvertedFromEAPMSCHAPV2=1>
# No EAP here, can reject with INTERNAL
<AuthBy INTERNAL>
DefaultResult REJECT
</Handler>
</Handler>
<Handler TunnelledByPEAP=1, Realm=something>
# Authenticate something
</Handler>
<Handler TunnelledByPEAP=1, Realm=somethingelse>
# Authenticate somethingelse
</Handler>
# Initial EAP message with no no EAP identity/username
# known yet, initiate desired inner EAP; or
# If not initial EAP message: it's an unexpected realm: reject
<Handler TunnelledByPEAP=1>
<AuthBy FILE>
EAPType EAP-MSCHAP-V2
Filename /dev/null
</Handler>
</Handler>
--
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
