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...