<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >hello</div>
<div dir="ltr" > </div>
<div dir="ltr" >wouldnt this be perfect for a Auth-Type check scenario ?</div>
<div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" ><br>Yours sincerely<br><br>Alfred Reibenschuh<br>Network-Management Architect<br>COE Network-Management-Services<br><br>Value Transformation Services GmbH<br>An IBM Company<br>Obere Donaustrasse 95<br>1020 Wien<br>Phone: +43-1-2056320-143<br>Mobile: +43-664-3523820</div>
<div dir="ltr" ><u><a href="mailto:Alfred.Reibenschuh_v-tservices@at.ibm.com">mail: Alfred.Reibenschuh_v-tservices@at.ibm.com<br>mail: VTSNMS@wwpdl.vnet.ibm.com</a></u><br>https://ibm.webex.com/join/alfred.reibenschuh_v-tservices<br><br>Please consider the environment before printing this e-mail.<br><br>This e-mail is confidential and may also contain privileged information. If you are not the intended recipient you are not authorized to read, print, save, process or disclose this message. If you have received this message by mistake, please inform the sender immediately and delete this e-mail, its attachments and any copies.<br>Any use, distribution, reproduction or disclosure by any person other than the intended recipient is strictly prohibited and the person responsible may incur penalties.<br>Thank you!</div></div></div></div></div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: radiator-request@lists.open.com.au<br>Sent by: "radiator" <radiator-bounces@lists.open.com.au><br>To: radiator@lists.open.com.au<br>Cc:<br>Subject: [EXTERNAL] radiator Digest, Vol 123, Issue 10<br>Date: Fri, Aug 23, 2019 14:00<br>
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >Send radiator mailing list submissions to<br>radiator@lists.open.com.au<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><a href="https://lists.open.com.au/mailman/listinfo/radiator" target="_blank">https://lists.open.com.au/mailman/listinfo/radiator</a> <br>or, via email, send a message with subject or body 'help' to<br>radiator-request@lists.open.com.au<br><br>You can reach the person managing the list at<br>radiator-owner@lists.open.com.au<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of radiator digest..."<br><br><br>Today's Topics:<br><br> 1. Re: "IgnoreIfMissing" required?<br> (Alexander.Hartmaier@t-systems.com)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 22 Aug 2019 16:06:32 +0000<br>From: <Alexander.Hartmaier@t-systems.com><br>To: <hvn@open.com.au>, <radiator@lists.open.com.au><br>Subject: Re: [RADIATOR] "IgnoreIfMissing" required?<br>Message-ID: <1566489997010.89745@t-systems.com><br>Content-Type: text/plain; charset="Windows-1252"<br><br>Hi Heikki,<br>thanks for the pointers!<br>Are you planning to add an easily configurable support for such a scenario?<br><br>Thanks, Alex<br><br>T-SYSTEMS AUSTRIA GESMBH<br>TCO Local Network Factory<br>Alexander Hartmaier<br>Operation Manager Authentication<br>Rennweg 97-99, A-1030 Vienna<br>+43 57057 4320 (phone)<br>+43 676 8642 4320 (mobile)<br>E-mail: alexander.hartmaier@t-systems.com<br><a href="http://www.t-systems.at" target="_blank">http://www.t-systems.at</a> <br><a href="http://blog.t-systems.at" target="_blank">http://blog.t-systems.at</a> <br><br>BIG CHANGES START SMALL ? CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.<br><br>******************************************************************<br>T-Systems Austria GesmbH, Rennweg 97-99, A-1030 Vienna<br>Commercial Court Vienna, FN 79340b<br>**********************************************************************************<br>Notice: This e-mail contains information that is confidential and may be<br>privileged. If you are not the intended recipient, please notify the sender<br>and then delete this e-mail immediately.<br>**********************************************************************************<br><br>________________________________________<br>Von: radiator <radiator-bounces@lists.open.com.au> im Auftrag von Heikki Vatiainen <hvn@open.com.au><br>Gesendet: Dienstag, 20. August 2019 13:05<br>An: radiator@lists.open.com.au<br>Betreff: Re: [RADIATOR] "IgnoreIfMissing" required?<br><br>On 14/08/2019 11.35, Alexander.Hartmaier@t-systems.com wrote:<br><br>> We have multiple AuthBys per handler, e.g. one FILE, three LDAP2, one SQL.<br>> As AuthBy LDAP2 returns a reject for both user not found and incorrect password we have configured AuthByPolicy ContinueUntilAccept in the Handler.<br>> 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'.<br>><br>> We'd like to stop trying further AuthBys when one finds the user but the password is incorrect to make troubleshooting such issues easier.<br>><br>> I can't think if a way to use AcceptIfMissing in combination with AuthByPolicy to do this and think a IgnoreIfMissing would be helpful.<br>><br>> Any advise if that's possible without hooks?<br><br>Can't think a good way to do this without hooks.<br><br>With hooks I'd consider PostAuthHook within AuthBy LDAP2 to switch<br>result argument to, for example, ignore if it looks like the user was<br>not found.<br><br>A simple method could be to look at the reason. A more controlled method<br>could be to use a PostSearchHook to add a marker attribute in $p when<br>there was a result and user was found. The PostAuthHook could then use<br>the presence of this attribute for deciding if the result should be changed.<br><br>In short: flag in PostSearchHook, act in PostAuthHook. All this within<br>AuthBy LDAP2.<br><br>Thanks,<br>Heikki<br><br>--<br>Heikki Vatiainen <hvn@open.com.au><br><br>Radiator: the most portable, flexible and configurable RADIUS server<br>anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,<br>EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,<br>DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.<br>_______________________________________________<br>radiator mailing list<br>radiator@lists.open.com.au<br><a href="https://lists.open.com.au/mailman/listinfo/radiator" target="_blank">https://lists.open.com.au/mailman/listinfo/radiator</a> <br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>radiator mailing list<br>radiator@lists.open.com.au<br><a href="https://lists.open.com.au/mailman/listinfo/radiator" target="_blank">https://lists.open.com.au/mailman/listinfo/radiator</a> <br><br>------------------------------<br><br>End of radiator Digest, Vol 123, Issue 10<br>*****************************************</font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>