SASL binds - Rambling...

[Phil Mayers]

On 23/02/15 20:34, Arran Cudbard-Bell wrote:
> Does anyone have a use for SASL binds in LDAP?

It might be useful if someone wanted to use GSSAPI-authed LDAP with a 
kerberos service ticket, if LDAP "simple" binds were disallowed. For 
example, run FR under a script that gets and refreshes a kerberos ticket 
from a keytab.

But it's a distinctly theoretical thing!

> I added an option to call ldap_sasl_bind for 3.0.7 but that was
> mostly to allow EXTERNAL auth for when FreeRADIUS is talking to LDAP
> over a unix socket, or authenticating with a client certificate.
>
> I was mainly looking at it to use NTLM binds against AD. But looking
> at MSCHAPv2 and NTLM auth, they're not compatible.
>
> It's still potentially useful to get access to the SSPI interface on
> AD via LDAP, which might allow custom LSA plugins to be called. I'm

Not sure I understand what you mean?

> not sure if a custom LSA plugin could be developed that could be used
> to implement the authenticator response part of MSCHAPv2, but that
> could potentially allow very fast authentication against AD.
>
> Has anyone used the LSA interface before, could a plugin be written
> to do that?

Do you mean LSA, or SSPI?

If you're talking to AD via LDAP, you can't access the LSA - you can 
only interact with a remote SSPI method by making GSS exchanges.

In theory I guess you could write an SSPI provider that "did" MSCHAP and 
interact with that over LDAP/GSSAPI.

It would be a lot of work; SSPI providers are not simple.

Server-side, that would need to back onto the LSA (the APIs for which 
are really, really complex - I never once managed to do an MSCHAP call 
successfully!) to do the actual MSCHAP calcs, and of course it would 
need to be installed on the domain controllers.

I can tell you right now, many windows shops will balk at installing 
anything on their DCs. For that reason I don't think it's a very useful 
approach :o(

For talking to Windows auths, right now and for the forseeable future I 
think we're stuck with the Netlogon RPCs, and Samba as the bridge into them.

I'm more concerned about what happens when the shoe drops about MSCHAP 
security and a replacement appears, and Microsoft contrive to make it 
hard for 3rd parties to check against AD on the grounds of security:

"""
We don't provide RPC calls to perform the EAP-PWD exchange, because they 
could be abused by malware. For that reason, the EAP exchange must be 
done with Microsoft NPS 2016 edition.
"""

Shudder...