2-step auth LDAP + Proxy

[Mathias Sundman]

> On 30 Dec 2017, at 15:04, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Dec 30, 2017, at 4:41 AM, Mathias Sundman <mathias at nilings.se> wrote:
>> 
>> 
>> Just in case someone else is searching for the same problem, I’ve cleaned up the logic to make it work with multiple virtual servers where I manually force proxying to a specific Realm, instead of relying on the suffix/realm module to enable the proxying. This is now what I ended up with:
> 
>  Updating a page on the Wiki would be nice, too. :)

I have a look at that when we’re happy with the logic :) I don’t wanna make a wiki page with something that “just works”, but it plain wrong.

> 
>> authorize {
>>       if (!State) {
>>               ldap
>>               if (ok) {
>>                       update control {
>>                               Auth-Type := LDAP
>>                       }
> 
>  That shouldn't be necessary.  i.e. if you have a standards-compliant LDAP server, it can return the "known good" password, and the PAP module can check the password.

My LDAP source is Active Directory, so I don’t think the LDAP module can get the "known good” password. Instead I need to force authentication by trying to re-bind as the authenticating user.

> 
>>               ldap
> 
>  This should probably be the "pap" module.

See above. As I wish to authenticate by having the ldap module rebinding, I think it needs to be “ldap” - right? 

I’m aware it’s generally recommended to use Samba and ntlm_auth instead for AD authentication, but as we provide a 2FA service to external customers and we don’t manage their AD, it’s cleaner to just request an LDAP service account in their AD to perform the authentication.

> 
>>               if (ok) {
>>                       update session-state {
>>                               Tmp-Integer-0 := "%{randstr:n}"
>>                       }
> 
>  Why are you updating the session-state here?  That's not the State attribute.  You should be updating the state attribute in the reply.

I got that from the “challenge” site example, and it seems to trigger a random State to be created. Without it, no state is created. I guess it’s a dirty work-around instead of manually setting the State attribute.

> 
>>                       update reply {
>>                               Reply-Message := "Please enter OTP"
>>                       }
>>                       challenge
>>               }
>>       }
>> }
>> 
>> pre-proxy {
>>       attr_filter.pre-proxy
>> }
>> 
>> If you believe the logic is still flawed in any way, please let me know, otherwise I thank you again Alan for the quick reply and consider the problem solved.