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