SASL binds - Rambling...
Does anyone have a use for SASL binds in LDAP? 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 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? As a result of playing about with libldap/SASL I now have some code that calls ldap_sasl_interactive_bind, implements an interact callback, and feeds back values for the standard challenges to get the auth/autz identity, the realm and the password. Has anyone been secretly hoping/wishing that one day rlm_ldap might be able to do SASLy things? # SASL parameters to use for user binds # # When we're prompted by the SASL library, these control # the responses given. # # Any of the config items below may be an attribute ref # or and expansion, so different SASL mechs, proxy IDs # and realms may be used for different users. sasl_mech = 'PLAIN EXTERNAL FOO' sasl PLAIN { identity = &User-Name # SASL authorisation identity to proxy. # proxy = &Another-User-Name # SASL realm. Used for kerberos. # realm = 'example.org' } -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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...
On Tue, Feb 24, 2015 at 12:01:37PM +0000, Phil Mayers wrote:
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(
Agreed - I can't get traction on putting some load-balancers (for LDAP resilience) in *front* of the DCs, let alone configuring anything on them. This is NAT-based load-balancers that don't need to touch the DCs themselves. There's plenty of need, it's tested and works fine, but "it's the DCs"...
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: ... Shudder...
Push towards EAP-TTLS/PAP? More clients are supporting it (Windows 7 the only major exception), and *much* more flexible on the RADIUS side. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 24/02/15 13:02, Matthew Newton wrote:
Push towards EAP-TTLS/PAP? More clients are supporting it (Windows 7 the only major exception), and *much* more flexible on the RADIUS side.
I'm not sure how that helps. MSCHAP is already embedded inside TLS for PEAP, so any concerns about MSCHAP imply concerns about PEAP, most likely the difficulty of ensuring proper CA trust settings on clients (cough, Android, cough). IMO, ensuring (as opposed to attempting) proper client setup is just too hard for PKIX-based systems in large organisations unless you spend a lot of money on a supplicant deployment tool. This sucks, and the supplicant/OS vendors need to get their shit together and fix cross-platform provisioning. I really wish EAP-PWD had identity privacy... and maybe a more mature cryptanalysis ;o) Basically, the state of EAP methods and provisioning sucks. It's a classic IT industry outcome, get 90% of the way there and stop, distracted, by the new shiny, leaving the ops community holding the bag! TEAP support? <crickets>
On Tue, Feb 24, 2015 at 01:43:47PM +0000, Phil Mayers wrote:
On 24/02/15 13:02, Matthew Newton wrote:
Push towards EAP-TTLS/PAP? More clients are supporting it (Windows 7 the only major exception), and *much* more flexible on the RADIUS side.
I'm not sure how that helps.
Well with EAP-TTLS/PAP, the RADIUS server gets the plaintext password from the client, so can do whatever backend auth mechanism it likes... I'm not thinking about security concerns handling plain passwords; we can be as protective about the RADIUS server as the Windows guys can be about their DCs, and the NTLM hash is nearly as good as plaintext anyway, hence the reason they may want to kill it off.
IMO, ensuring (as opposed to attempting) proper client setup is just too hard for PKIX-based systems in large organisations unless you spend a lot of money on a supplicant deployment tool. This sucks, and the supplicant/OS vendors need to get their shit together and fix cross-platform provisioning.
Agreed. EAP-TLS would be a lot nicer, but requires a lot more effort for on-boarding. We have enough complaints about the client setup processes as it is (and they really aren't that hard).
Basically, the state of EAP methods and provisioning sucks. It's a
It's the usual story with something "extensible". You end up having to run the lowest common denominator, which is probably tantamount to crap. SSL and crypto algorithms, anyone? Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 24 Feb 2015, at 09:09, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
th EAP-TTLS/PAP, the RADIUS server gets the plaintext password from the client, so can do whatever backend auth mechanism it likes...
I'm not thinking about security concerns handling plain passwords; we can be as protective about the RADIUS server as the Windows guys can be about their DCs, and the NTLM hash is nearly as good as plaintext anyway, hence the reason they may want to kill it off.
IMO, ensuring (as opposed to attempting) proper client setup is just too hard for PKIX-based systems in large organisations unless you spend a lot of money on a supplicant deployment tool. This sucks, and the supplicant/OS vendors need to get their shit together and fix cross-platform provisioning.
Agreed. EAP-TLS would be a lot nicer, but requires a lot more effort for on-boarding. We have enough complaints about the client setup processes as it is (and they really aren't that hard).
Basically, the state of EAP methods and provisioning sucks. It's a
It's the usual story with something "extensible". You end up having to run the lowest common denominator, which is probably
EAP-PWD seems like the perfect solution, except they don't have an extensible framework for password preprocessing. Seems like you either do no processing, NTLM type preprocessing, or UTF8 canonicalisation. There's no support for other hashing scheme. It seems like a massive oversight. Regarding LSA/SSPI, I was lead to believe by the Microsoft docs that LSA plugins could be called via the SSPI interface, with the SSPI interface being accessible from LDAP SASL binds. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
"Arran" == Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
Arran> Regarding LSA/SSPI, I was lead to believe by the Microsoft Arran> docs that LSA plugins could be called via the SSPI interface, Arran> with the SSPI interface being accessible from LDAP SASL Arran> binds. Uh, sort of. SSPI is a lot closer to GSS-API than to SASL. Microsoft doesn't really have a good layer for implementing the layer that would bridge between SASL and SSPI/GSS-API. The gss-eap SSP (RFC 7055/Moonshot as an SSP) has never been tested interoperably as a SASL mechanism. I suspect it would work between two Windows boxes for some applications, bxut very much not work say between a Windows box and cyrus-sasl or gsasl. It's possible work could be done along these lines if someone wanted to, but it won't come cheaply. writing an SSP tends to be fairly involved and tends to involve fairly complex/lrong/expensive debugging sessions. Sam hartman Principal Consultant Painless Security, LLC
participants (4)
-
Arran Cudbard-Bell -
Matthew Newton -
Phil Mayers -
Sam Hartman