Re: [RADIATOR] "IgnoreIfMissing" required?
On 27/08/2019 18.28, alexander.hartma...@t-systems.com wrote: My idea was to add an IgnoreIfMissing to all AuthBys and configure AuthByPolicy ContinueWhileIgnore. This is now in the latest patches and will be part of next release. Radiator packages with patches are available from the usual download site. Thank you, and also thanks Christian, for suggesting this. Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] "IgnoreIfMissing" required?
Hi Heikki, you mean Christian? My idea was to add an IgnoreIfMissing to all AuthBys and configure AuthByPolicy ContinueWhileIgnore. Best regards, Alex T-SYSTEMS AUSTRIA GESMBH TCO Local Network Factory Alexander Hartmaier Operation Manager Authentication Rennweg 97-99, A-1030 Vienna +43 57057 4320 (phone) +43 676 8642 4320 (mobile) E-mail: alexander.hartma...@t-systems.com http://www.t-systems.at http://blog.t-systems.at BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ** T-Systems Austria GesmbH, Rennweg 97-99, A-1030 Vienna Commercial Court Vienna, FN 79340b ** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. ** Von: radiator im Auftrag von Heikki Vatiainen Gesendet: Montag, 26. August 2019 14:45 An: radiator@lists.open.com.au Betreff: Re: [RADIATOR] "IgnoreIfMissing" required? On 22/08/2019 19.06, alexander.hartma...@t-systems.com wrote: > thanks for the pointers! > Are you planning to add an easily configurable support for such a scenario? We'll need to think about this. About the idea Alfred suggested, do you think that would suit your needs? Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] "IgnoreIfMissing" required?
Hi Heikki, thanks for the pointers! Are you planning to add an easily configurable support for such a scenario? Thanks, Alex T-SYSTEMS AUSTRIA GESMBH TCO Local Network Factory Alexander Hartmaier Operation Manager Authentication Rennweg 97-99, A-1030 Vienna +43 57057 4320 (phone) +43 676 8642 4320 (mobile) E-mail: alexander.hartma...@t-systems.com http://www.t-systems.at http://blog.t-systems.at BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ** T-Systems Austria GesmbH, Rennweg 97-99, A-1030 Vienna Commercial Court Vienna, FN 79340b ** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. ** Von: radiator im Auftrag von Heikki Vatiainen Gesendet: Dienstag, 20. August 2019 13:05 An: radiator@lists.open.com.au Betreff: Re: [RADIATOR] "IgnoreIfMissing" required? On 14/08/2019 11.35, alexander.hartma...@t-systems.com wrote: > We have multiple AuthBys per handler, e.g. one FILE, three LDAP2, one SQL. > As AuthBy LDAP2 returns a reject for both user not found and incorrect > password we have configured AuthByPolicy ContinueUntilAccept in the Handler. > The issue we have with this config is the logging: if a user enters an > incorrect password and the user isn't found by the last AuthBy but one of the > four previous ones, it is skipped and the last one returns 'no such user'. > > We'd like to stop trying further AuthBys when one finds the user but the > password is incorrect to make troubleshooting such issues easier. > > I can't think if a way to use AcceptIfMissing in combination with > AuthByPolicy to do this and think a IgnoreIfMissing would be helpful. > > Any advise if that's possible without hooks? Can't think a good way to do this without hooks. With hooks I'd consider PostAuthHook within AuthBy LDAP2 to switch result argument to, for example, ignore if it looks like the user was not found. A simple method could be to look at the reason. A more controlled method could be to use a PostSearchHook to add a marker attribute in $p when there was a result and user was found. The PostAuthHook could then use the presence of this attribute for deciding if the result should be changed. In short: flag in PostSearchHook, act in PostAuthHook. All this within AuthBy LDAP2. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] "IgnoreIfMissing" required?
Hello Christian - I am not suggesting another AuthBy FILE - you can do the same thing in RADMIN. The example was simply to show you how Radiator works with multiple DEFAULT, DEFAULT1, DEFAULT2, etc. regards Hugh > On 20 Jan 2019, at 21:14, Christian Meutes wrote: > > Hey Hugh, > > On Sun, Jan 20, 2019 at 2:30 AM Hugh Irvine wrote: >> DEFAULT User-Name = /hugh/ >>Reply-Message = DEFAULT >> >> DEFAULT1 User-Name = /christian/ >>Reply-Message = DEFAULT1 > > I'm not able to see how indroducing another 'AuthBy FILE' can help me > with my logic, apologies. > I do understand how to use a user file with DEFAULT and further > check-items. But I think I really need to use this inside of RADMIN, > because having another 'AuthBy FILE' right after RADMIN would mean not > being able to differentiate anymore between "user not found and user > found and accepted (AcceptIfMissing)" or "user not found and user > rejected (default logic)". In the former case (user found and > accepted) it would still consult LDAP. In the latter case it would not > consult LDAP anymore. > > Thanks / Best regards > -- > Christian -- Hugh Irvine h...@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. ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] "IgnoreIfMissing" required?
Hey Hugh, On Sun, Jan 20, 2019 at 2:30 AM Hugh Irvine wrote: > DEFAULT User-Name = /hugh/ > Reply-Message = DEFAULT > > DEFAULT1 User-Name = /christian/ > Reply-Message = DEFAULT1 I'm not able to see how indroducing another 'AuthBy FILE' can help me with my logic, apologies. I do understand how to use a user file with DEFAULT and further check-items. But I think I really need to use this inside of RADMIN, because having another 'AuthBy FILE' right after RADMIN would mean not being able to differentiate anymore between "user not found and user found and accepted (AcceptIfMissing)" or "user not found and user rejected (default logic)". In the former case (user found and accepted) it would still consult LDAP. In the latter case it would not consult LDAP anymore. Thanks / Best regards -- Christian ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] "IgnoreIfMissing" required?
Hi Christian - You can use multiple entries like this (which is what Radiator actually does): DEFAULT User-Name = /…../ ….. DEFAULT1 User-Name = /…../ ….. DEFAULT2 User-Name = /…../ …… regards Hugh this users file DEFAULT User-Name = /hugh/ Reply-Message = DEFAULT DEFAULT1 User-Name = /christian/ Reply-Message = DEFAULT1 gives this TiTi:Radiator-4.22 hugh$ perl radpwtst -user hugh -noacct sending Access-Request Sun Jan 20 12:25:46 2019: DEBUG: Packet dump: *** Received from 127.0.0.1 port 51846 Code: Access-Request Identifier: 128 Authentic: <140><155>?c<169><233><232><186>)O<187><209>x<198>O; Attributes: User-Name = "hugh" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = "203.63.154.1" NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Async User-Password = <249><192><157><15>A?<208><174><205><136>K<22>[<243><173>J Sun Jan 20 12:25:46 2019: DEBUG: Handling request with Handler '', Identifier '' Sun Jan 20 12:25:46 2019: DEBUG: SessINTERNAL: Deleting session for hugh, 203.63.154.1, 1234 Sun Jan 20 12:25:46 2019: DEBUG: Handling with Radius::AuthFILE: Sun Jan 20 12:25:46 2019: DEBUG: Radius::AuthFILE looks for match with hugh [hugh] Sun Jan 20 12:25:46 2019: DEBUG: Radius::AuthFILE REJECT: No such user: hugh [hugh] Sun Jan 20 12:25:46 2019: DEBUG: Radius::AuthFILE looks for match with DEFAULT [hugh] Sun Jan 20 12:25:46 2019: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT [hugh] Sun Jan 20 12:25:46 2019: DEBUG: AuthBy FILE result: ACCEPT, Sun Jan 20 12:25:46 2019: DEBUG: Access accepted for hugh Sun Jan 20 12:25:46 2019: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 51846 Code: Access-Accept Identifier: 128 Authentic: <23>:P<234>r_UQ<27>_<248><162><138><132>e<151> Attributes: Reply-Message = "DEFAULT" OK TiTi:Radiator-4.22 hugh$ perl radpwtst -user christian -noacct sending Access-Request Sun Jan 20 12:26:01 2019: DEBUG: Packet dump: *** Received from 127.0.0.1 port 50283 Code: Access-Request Identifier: 198 Authentic: <217><14> &<250>CJ<225><150>l<190><255>X>)_ Attributes: User-Name = "christian" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = "203.63.154.1" NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Async User-Password = 4<14><171><244>>+<239><24>p<208><211><23>jl6<16> Sun Jan 20 12:26:01 2019: DEBUG: Handling request with Handler '', Identifier '' Sun Jan 20 12:26:01 2019: DEBUG: SessINTERNAL: Deleting session for christian, 203.63.154.1, 1234 Sun Jan 20 12:26:01 2019: DEBUG: Handling with Radius::AuthFILE: Sun Jan 20 12:26:01 2019: DEBUG: Radius::AuthFILE looks for match with christian [christian] Sun Jan 20 12:26:01 2019: DEBUG: Radius::AuthFILE REJECT: No such user: christian [christian] Sun Jan 20 12:26:01 2019: DEBUG: Radius::AuthFILE looks for match with DEFAULT [christian] Sun Jan 20 12:26:01 2019: DEBUG: Radius::AuthFILE REJECT: Check item User-Name expression '/hugh/' does not match 'christian' in request: DEFAULT [christian] Sun Jan 20 12:26:01 2019: DEBUG: Radius::AuthFILE looks for match with DEFAULT1 [christian] Sun Jan 20 12:26:01 2019: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT1 [christian] Sun Jan 20 12:26:01 2019: DEBUG: AuthBy FILE result: ACCEPT, Sun Jan 20 12:26:01 2019: DEBUG: Access accepted for christian Sun Jan 20 12:26:01 2019: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 50283 Code: Access-Accept Identifier: 198 Authentic: D<146>.<209> <193><134>}n<165> <16><22><137>n<186> Attributes: Reply-Message = "DEFAULT1" OK > On 20 Jan 2019, at 10:24, Christian Meutes wrote: > > Hi Hugh. > > On Sat, Jan 19, 2019 at 10:52 PM Hugh Irvine wrote: >> 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? > > the RADMIN 'RADUSERS'-table has an index on the 'USERNAME'-column > which has the unique constraint. Creating multiple users with > 'DEFAULT' as username doesn't work there. :-( > > Thanks > -- > Christian -- Hugh Irvine h...@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. ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] "IgnoreIfMissing" required?
Hi Hugh. On Sat, Jan 19, 2019 at 10:52 PM Hugh Irvine wrote: > 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? the RADMIN 'RADUSERS'-table has an index on the 'USERNAME'-column which has the unique constraint. Creating multiple users with 'DEFAULT' as username doesn't work there. :-( Thanks -- Christian ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] "IgnoreIfMissing" required?
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 wrote:
>
> Hello Hugh,
>
> On Sat, Jan 19, 2019 at 4:24 AM Hugh Irvine 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
> 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
> 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 #
> #
>
>
>Identifier AuthByGroup-CorpWifi
>AuthByPolicy ContinueWhileAccept
># EAP-TLS - mandatory (only valid certificates are allowed)
>
>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
Re: [RADIATOR] "IgnoreIfMissing" required?
Hello Christian - 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. regards Hugh > On 19 Jan 2019, at 10:44, Christian Meutes wrote: > > Hi Hugh, > > On Sat, Jan 19, 2019 at 12:12 AM Hugh Irvine wrote: > >> >> >>AuthByPolicy ContinueWhileIgnore >> >> >> >>AuthByPolicy ContinueUntilAccept >> >> >>….. >> >> >> >>….. >> >> >> >> >> >>….. >> >> >> > > hmmm ... I believe the "Reject" in Radmin, when a user is found but > explicitely denied by check-items, wouldn't be possible with this. Or > am I wrong? > > Thanks, > -- > Christian > > PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318 > Toulouser Allee 21, 40211 Duesseldorf, Germany -- Hugh Irvine h...@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. ___ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator
