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 <[email protected]> wrote:
>
> Hello Hugh,
>
> On Sat, Jan 19, 2019 at 4:24 AM Hugh Irvine <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> 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@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
[email protected]
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.
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
