[RADIATOR] eap auth against active directory

[James Zee]

I imagine that an alternative would be to have a more broad NPS "connection
request policy" or "network policy", instead of having Radiator tag the
ACCESS-REQUEST with a fake NAS port type.

Maybe I could pose a more broad question: when configuring NPS as the final
authenticator in a proxied RADIUS request, does anyone have any tips on
configuring the connection request policy or the network policies?

Thanks!
-james


On Tue, Oct 9, 2012 at 2:44 PM, James Zee <jameszee13 at gmail.com> wrote:

> All,
>
> Thanks for the response.
>
> We've decided against using winbind / ntlm_auth. Unfortunately our AD
> environment is so sporadic and bumpy that we're desperate for another
> solution.
>
> So we're attempting to test Radiator proxying requests through to NPS.
>
> I've set up a few NPS servers and put them behind a load balancer. I've
> used eapol_test (found in wpa_supplicant package) to test EAP RADIUS
> requests to NPS. This works fine and seems to be extremely stable, even
> when the Active Directory DCs are not.
>
> Unfortunately, however, when we proxy our EAP requests through Radiator,
> NPS sends an ACCESS-REJECT back without much logging. From what I can tell,
> NPS is not responding because the RADIUS message that is proxied through
> Radiator does not have a valid NAS port type.
>
> Shouldn't the proxied request include a NAS port type? Is there a way to
> "fake" or append a NAS port type to the RADIUS request?
>
> Any thoughts appreciated.
>
> Thanks!
> -james
>
>
>
>
> On Mon, Oct 1, 2012 at 6:32 PM, David Zych <dmrz at illinois.edu> wrote:
>
>> > Because we're bouncing off of AD, we're relying on ntlm_auth to check a
>> > user's credentials. Unfortunately our specific Active Directory
>> environment
>> > is *very* unstable with DCs randomly rebooting / being upgraded. This
>> > results in issues when ntlm_auth is run, such as:
>> >
>> > (a) NTLM Could not authenticate user 'USERNAME': NT_STATUS_IO_TIMEOUT
>> > (b) NTLM Could not authenticate user 'USERNAME': Access denied
>> >
>> > When things break badly and all ntlm_auth requests return one of these
>> > errors, the only way to fix this is to unbind from the domain, then
>> rebind
>> > with a "net join".
>>
>> Have you tried simply restarting winbind?  Though our AD is fairly
>> stable, I still see these symptoms from time to time, but in my case
>> restarting winbind (via its init.d script) causes ntlm_auth to work
>> again without having to actually rejoin the domain.
>>
>> > The big issue here is that Samba / winbind seems to tie itself to *one*
>> > domain controller -- it doesn't seem to automatically query another DC
>> when
>> > something breaks with the DC ntlm_auth is currently using.
>>
>> This may or may not be relevant (I'm no AD or samba expert), but I have
>> in my smb.conf:
>>
>> password server = *
>>
>> as opposed to specifying a single DC.  I suspect that perhaps this helps
>> winbind to pick a different DC when I restart it.
>>
>> I also notice that /var/lib/samba/smb_krb5/krb5.conf.MYDOMAINHERE has a
>> bunch of different "kdc" IPs listed under the realm, which strikes me as
>> a good and useful thing.  I didn't do anything manually to make that
>> happen, though; this file was automatically generated by samba (I think
>> when I first joined each linux box to the domain).
>>
>> > (ii) since I assume ntlm_auth is the only way to easily authenticate,
>> has
>> > anyone found a robust way to depend on Samba / winbind?
>>
>> The secret to my success is a cron script on each server which tests
>> that full MSCHAP authentication vs AD (using the Samba secure pipe) is
>> working properly and, if not, restarts winbind in an attempt to
>> self-heal.  This nips a lot of problems in the bud within 1 minute with
>> no human intervention required.
>>
>> Hope this helps at least somewhat,
>> David
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20121009/cdc0ee14/attachment.html