Forum Discussion
THi
Nimbostratus
NimbostratusAPM AD auth and LDAP request signing
Microsoft intends to require LDAP singing by default in their upcoming January 2020 server security updates. See https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows. This to mitigate certain LDAP vulnerabilities.
In APM, AD Auth uses LDAP SASL GSS-API/Kerberos to implement the user authentication. However it seems that the actual LDAP AS-Requests are not signed (at least in sw 14.1.x), nor there seem to be any option to sign those. This means they can possibly be used for elevation of privilege. Using Kerberos Pre-Auhentication reduces the risk somewhat, but to my understanding, does not remove it fully.
For an APM 14.1.2.1 authentication request, the AD logs indicate:
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.
Client IP address:
x.x.x.x:38874
Identity the client attempted to authenticate as:
DOMAINX\svc-f5-account-x
Binding Type:
0Binding type should be "1" to indicate signed request.
Is there any way to get the LDAP requests signed? I would not like to go to LDAP Auth using LDAPS as a workaround to enhance security.
Dave_WEmployee
Hello, at this point it looks like F5 is recommending to use LDAPS and change AD Query to LDAP Query.
- THi
I think F5 should consider an RFE for LDAP request singing instead of using LDAP Query, as I believe the AD Auth is used in most APM authentication deployments against AD. Using LDAPS query will be a major reconfig in some cases..
- Dave_W
I did some checking and it appears there is a doc update RFE. Apparently there has been some testing done with AD Query that was successful, HOWEVER more extensive testing has not been completed so I would not consider this technically supported yet. FYI.
Bm99F5 appear to have issued an article on the 8th Jan that appears to state there is no issue. https://support.f5.com/csp/article/K30054212
I really would have expected more detailed information regards to the APM AD and the mechanisms it supports for compliance purposes. Questions are now being asked if data is being passed in the clear. If I can't get more info I am going to have to switch to LDAPS. This was the original recommendation from support at the tail end of 2019 which is worst case. We still have our DC's configured to provide more detailed logs and see the event 2889 as a result of the F5 making an unsigned LDAP bind. Hopefully we will get more information soon, I will also keep chasing my SE for an more definitive answer.
- THi
In November we did some tcpdumps when APM did the AD Auth (14.1.x sw). Using wireshark on the dumps we saw that there were no signing of the LDAP SASL binding requests. ALso the AD event log indicated the same. The K30054212 recommendation "No changes are required for LDAPS or Active Directory AAA servers" may need some more clarification?
action_-Altostratus
So, I was looking into this and our DCs are already configured for this due to DoD STIGs from looking at the registry.
We're on 14.1.2.2
Use AAA Active Directory for APM AD Queries, SSO Kerberos, and also logging into f5 with AD accounts for the management GUI.
There are EventCode 2889 in my event logs when I enable the LDAP Interface Events debug logging, but the "BindType" field doesn't exist, so not sure. There are no issues as far as I can tell.
Anyone experiencing otherwise?