[RADIATOR] "IgnoreIfMissing" required?
Christian Meutes
christian at errxtx.net
Sat Jan 19 11:58:17 UTC 2019
Hello Hugh,
On Sat, Jan 19, 2019 at 4:24 AM Hugh Irvine <hugh at open.com.au> wrote:
> My assumption was that your users would be primarily in RADMIN, and if not there then in LDAP?
>
> Perhaps you could clarify? More detail on exactly what you are trying to accomplish would be helpful.
ok, I will try to be verbose.
The main thing I'am right now working on is really just this logic:
On Fri, Jan 18, 2019 at 12:21 PM Christian Meutes <christian at errxtx.net> wrote:
> (1) First AuthBy/Backend (Radmin/SQL): If user found either 'Accept'
> or 'Reject' depending on check-item result. If user is not found, try
> out the second backend.
>
> (2) Second AuthBy/Backend (LDAP): If user found then 'Accept' or do
> 'Reject' if not found.
What was probably not so clear is the "If user found either 'Accept'
or 'Reject' depending on ..". Meant by that was that the RADMIN AuthBy
is the last AuthBy taking affect when the user is found. OTOH only
when the user is not found the next AuthBy (LDAP) is used/meaningful.
Why this all? You are right LDAP is the main backend for users. This
large and complex directory is the main source for allowing a user in
by checking for a appropriate user DN (the user just needs to exist
there, passwords are not checked, the real first factor authentication
is EAP-TLS in this chain).
Now, to obtain some flexibility, I want to make use of check- and
reply-items (which is not possible with our LDAP) by using RADMIN
right after EAP-TLS and before LDAP. When a user is there, then RADMIN
is the final backend to consult and decide everything on. On the other
hand, when we don't have a specific setting for a user in RADMIN, then
still the user must exist *somewhere*, otherwise he will be denied, so
he must exist in LDAP when he does not exist in RADMIN (RADMIN is the
more specific LDAP-overruling backend).
On Sat, Jan 19, 2019 at 12:09 AM Christian Meutes <christian at errxtx.net> wrote:
> - I used 'AddToRequest Realm=foobar' inside the handler to get some
> unique identifier to use a check-item in the DEFAULT user entry in
> Radmin.
> Unfortunately this didn't work out: 'AddToRequest' doesn't seem to
> add the Realm attribute to the 'Access-Request' (the check does fail
> and 'PacketTrace' nor 'trace 5' gives any insights about the reason).
This does definitely not work - I'm not able to add attributes in my
authentication Handler (but this is another issue, and not really
necessary in my scenario, just as a side note meant).
> - By leveraging a random attribute from the original packet the match
> does work for the new 'DEFAULT' user finally. But then the above
> reply-item ("Auth-Type=Ignore") seems to fail for unknown reason
> again. The log says: "WARNING: Invalid reply item Auth-Type ignored".
This was my mistake, I overlooked that 'Auth-Type' is a check-item and
not a reply-item!
Now I'am able to jump right away to the LDAP AuthBy if the user is not
found in RADMIN (by leveraging the 'DEFAULT' user in RADMIN).
> Beside these issues I also wonder how to differentiate this DEFAULT
> user in Radmin from any other possible DEFAULT user used for other
> realms/handlers/use-cases in future.
So I have more or less a solution now. Just this single 'DEFAULT' user
in RADMIN is not really scalable. Reason is that I use RADMIN not only
for this Handler/processing-flow but also for others (one of the
reasons why I rewrite/append to every username a unique realm/suffix).
Ideally the 'DEFAULT' lookup could be done on multiple indices
('WHERE' clause) or one could append a realm to 'DEFAULT'
("DEFAULT at foobar") inside of an AuthBy... (no matter how, this will
come back again, in other 'DEFAULT' user use cases).
For even more verbosity I did attach the whole Handler configuration below.
Hopefully not too much verbosity now. :-)
Thanks and a good weekend!
--
Christian
######################
# Authentication AuthBys #
#####################
<AuthBy GROUP>
Identifier AuthByGroup-CorpWifi
AuthByPolicy ContinueWhileAccept
# EAP-TLS - mandatory (only valid certificates are allowed)
<AuthBy FILE>
Identifier AuthByFile-CorpWifi-EAPTLS
# this file has no real function but might need to exist
Filename %D/users.eaptls
AuthenProto EAP
EAPType TLS
EAPErrorReject
EAPTLS_NoCheckId
EAPTLS_CAPath /etc/pki/tls/certs/xxx/CA
EAPTLS_CertificateFile /etc/pki/tls/certs/xxx/xxx.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/pki/tls/certs/xxx/xxx.key.pem
EAPTLS_MaxFragmentSize 1000
EAPTLS_CRLCheck
EAPTLS_CRLFile /etc/pki/tls/certs/xxx/xxx.crl
AutoMPPEKeys
# Debugging
Log LogFile-CorpWifi-AuthBy-Auth
#PacketTrace
</AuthBy>
<AuthBy GROUP>
Identifier AuthByGroup-CorpWifi-Backends
AuthByPolicy ContinueWhileIgnore
# SQL - User must not exist
# If user does exist, all following backends are skipped (eg. LDAP).
<AuthBy RADMIN>
Identifier AuthByRadmin-CorpWifi
RoundRobinOnFailure
DBSource dbi:mysql:xxx:y.y.y.y
DBUsername xxx
DBAuth xxx
DBSource dbi:mysql:xxx:y.y.y.y
DBUsername xxx
DBAuth xxx
AuthSelect select PASS_WORD, STATICADDRESS,
TIMELEFT,MAXLOGINS, SERVICENAME, BADLOGINS, VALIDFROM, VALIDTO from
RADUSERS where USERNAME=?
AuthSelectParam %0
ServiceAttrQuery select ATTR_ID, VENDOR_ID, IVALUE,
SVALUE, ITEM_TYPE from RADSTCONFIG where NAME=? order by ITEM_TYPE
UserAttrQuery select ATTR_ID, VENDOR_ID, IVALUE, SVALUE,
ITEM_TYPE from RADCONFIG where NAME=? order by ITEM_TYPE
AttrQueryParam %0
NoDefaultIfFound
NoCheckPassword
NoEAP
# Debugging
Log LogFile-CorpWifi-AuthBy-Auth
PacketTrace
</AuthBy>
# LDAP - User must exist, otherwise reject (if user exists in
RADMIN then LDAP is not used)
<AuthBy LDAP2>
Identifier AuthByLDAP2-CorpWifi
Host x.x.x.x y.y.y.y
AuthDN CN=xxx
AuthPassword xxx
BaseDN CN=xxx
Timeout 3
NoDefault
UsernameAttr CN
PasswordAttr
NoEAP
# Debugging
Log LogFile-CorpWifi-AuthBy-Auth
#Debug 8
#PacketTrace
</AuthBy>
# Catch Ignores (should be limited to protocol-errors from
previous backends)
# Therefore accept users who couldn't be looked up because of
non-functional backends (RADMIN, LDAP)
<AuthBy INTERNAL>
Identifier AuthByINTERNAL-CorpWifi-ACCEPT
AuthResult ACCEPT
# Debugging
Log LogFile-CorpWifi-AuthBy-Auth
PacketTrace
</AuthBy>
# Debugging
Log LogFile-CorpWifi-AuthBy-Auth
PacketTrace
</AuthBy>
# Debugging
Log LogFile-CorpWifi-AuthBy-Auth
PacketTrace
</AuthBy>
###################
# Accounting AuthBys #
###################
# Quota
<AuthBy RADMIN>
Identifier AuthByRadmin-CorpWifi-Quota
DBSource dbi:mysql:xxx:y.y.y.y
DBAuth xxx
AcctSQLStatement update RADUSERS set
TIMELEFT=TIMELEFT-0%{Acct-Session-Time},
OCTETSINLEFT=OCTETSINLEFT-0%{Acct-Input-Octets},
OCTETSOUTLEFT=OCTETSOUTLEFT-0%{Acct-Output-Octets} where USERNAME='%n'
# Debugging
Log LogFile-CorpWifi-AuthBy-Acct
#PacketTrace
</AuthBy>
#####################
# Authentication Handler #
#####################
<Handler Request-Type=Access-Request,NAS-Port-Type=/Wireless/,Called-Station-Id=/foobar/>
Identifier Handler-CorpWifi-Auth
RewriteUsername s/host\/(.*)/$1\@CorpWifi/
SessionDatabaseOptions UseRewrittenName
RejectHasReason
AuthBy AuthByGroup-CorpWifi
AuthLog Authlog-SQL
AuthLog Authlog-combined-FILE
# Debugging
Log LogFile-CorpWifi-Handler-Auth
PacketTrace
</Handler>
###################
# Accounting Handler #
##################
<Handler Request-Type=Accounting-Request,NAS-Port-Type=/Wireless/,Called-Station-Id=/foobar/</>
Identifier Handler-CorpWifi-Acct
AccountingAccepted
RewriteUsername s/host\/(.*)/$1\@CorpWifi/
SessionDatabaseOptions UseRewrittenName
AuthBy AuthByRadmin-CorpWifi-Quota
AcctLogFileName %L/accounting/files/corpwifi.log
AcctLog Acctlog-combined-JSON
# Debugging
Log LogFile-CorpWifi-Handler-Acct
#PacketTrace
</Handler>
More information about the radiator
mailing list