[RADIATOR] "IgnoreIfMissing" required?
Hugh Irvine
hugh at open.com.au
Sat Jan 19 21:51:58 UTC 2019
Hello Christian -
Well, you can have multiple DEFAULT entries like this:
DEFAULT User-Name = /something/
……
DEFAULT User-Name = /whatever/
…..
and so on.
Does that work for you?
regards
Hugh
> On 19 Jan 2019, at 22:58, Christian Meutes <christian at errxtx.net> wrote:
>
> 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>
--
Hugh Irvine
hugh at open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc.
Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare etc.
More information about the radiator
mailing list