Bug 47901 - AD Member setup fails if Active Driectory LDAP data signing is configured to "Require signature"
AD Member setup fails if Active Driectory LDAP data signing is configured to ...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: AD Connector
UCS 4.3
Other Linux
: P5 normal (vote)
: UCS 4.3-2-errata
Assigned To: Felix Botner
Arvid Requate
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-02 17:25 CEST by Arvid Requate
Modified: 2018-10-10 12:31 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 6: Setup Problem: Issue for the setup process
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.343
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support: Yes
Ticket number: 2018092721000451
Bug group (optional): Appliance
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2018-10-02 17:25:10 CEST
Ticket #2018092721000451 reports a failure of AD Member setup. The setup.log shows a traceback of a failing LDAP bind which contains the exact error message of the AD-DC:

ldap.STRONG_AUTH_REQUIRED: {'info': '00002028: LdapErr: DSID-0C090256, comment: The server requires binds to turn on integrity checking if SSL\\TLS are not already active on the connection, data 0, v3839', 'desc': 'Strong(er) authentication required'}

Under https://blog.scottlowe.org/2008/03/17/ldap-signing-in-ad-integration-situations/ and https://www.dirwiz.com/kb/346 I learned that MS Windows DCs offer a registry (GPO?) setting for AD-DCs, that configure "LDAP server signing":

===============================================================================
Domain controller: LDAP server signing requirements

This security setting determines whether the LDAP server requires signing to be negotiated with LDAP clients, as follows:

None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.

Require signature: Unless TLS\SSL is being used, the LDAP data signing option must be negotiated.

Default: Not defined, which has the same effect as None.
===============================================================================
See also https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements

The description of "Require signature" pretty much matches the error message.

According to https://www.ultimatewindowssecurity.com/wiki/page.aspx?spid=DCldap you either need to switch of the registry setting or use LDAPS. 

According to https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2010-February/001957.html there might be other options in the SASL GSSAPI code, but first I don't know if they implemented something like that and second it doesn't look like python-ldap SALS interactive bind offers any options for data signing.

We should test this
Comment 2 Arvid Requate univentionstaff 2018-10-02 18:06:50 CEST
The following workaround may be possible, but we would need to test that:


1. Install a "normal" UCS Master with the same domain name as the AD domain. Install the AD-Connection component, we'll need that in step 4.

2. Export the X509 certificate of the AD DC and convert it from DER to PEM

3. Set the following UCR variables, forcing the usage of SSL for LDAP.

ucr set connector/ad/ldap/certificate="/etc/univention/connector/ad/ad_cert_20181002.pem"  ## Name of the converted certificate

ucr set --force connector/ad/ldap/ssl=yes ldap/sasl/secprops/maxssf=128

4. Use the UMC module AD-Connection to set up the AD-Member mode.


But I'm not sure if the UMC AD-Connection wizard considers the SSL/TLS option during SASL interactive GSSAPI bind.
Comment 3 Arvid Requate univentionstaff 2018-10-02 18:17:22 CEST
An alternative (temporary, volatile) workaround could be to configure the UCS ldap client side to require integrity protection for SASL binds:

echo "sasl_secprops minssf=1" >> /etc/ldap/ldap.conf

So that would be: Setup UCS like in step 1 of Comment 2, then add that minssf option to ldap.conf and continue directly with step 4. If this works, we should add a UCR variable to allow making that option persistent.
Comment 5 Arvid Requate univentionstaff 2018-10-02 19:06:11 CEST
See https://tools.ietf.org/html/rfc4422 for SASL / GSSAPI "security layer"
See GSSAPI term "integrity" in https://tools.ietf.org/html/rfc4752
See Kerberos term "KRB_SAFE" in https://tools.ietf.org/html/rfc4120#page-42

We probably don't need to consider https://github.com/cyrusimap/cyrus-sasl/issues/419#issuecomment-383570149 , because we would only user either LDAPS (Comment 2) or maxssf=1 (Comment 3), but probably not both combined.
Comment 6 Felix Botner univentionstaff 2018-10-08 17:40:00 CEST
Seems that make-deleted-objects-readable-for-this-machine and well-known-sid-object-rename only support simple bind.

This fails if the AD server has ldapserverintegrity enabled 
computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters \ldapserverintegrity=2

-> ldapsearch -H ldap://WIN-M1LHUHEJFSI.w2k12.test -D CN=Administrator,CN=Users,DC=w2k12,DC=test  -w Univention.99
ldap_bind: Strong(er) authentication required (8)
	additional info: 00002028: LdapErr: DSID-0C090203, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v23f0

sasl/gssapi works.

-> kinit Administrator
-> ldapsearch -H ldap://WIN-M1LHUHEJFSI.w2k12.test -D CN=Administrator,CN=Users,DC=w2k12,DC=test -Y GSSAPI  -w Univention.99

So we should support sasl/gssapi in make-deleted-objects-readable-for-this-machine and well-known-sid-object-rename (it is already supported in univention-dsearch and the connector itself)

f1b6ca73ddcdaca5fed0226198e880c65874f27e - univention-ad-connector
df85e4b7d151e66140e408260c63e0bcf9245c91 - yaml
Comment 7 Arvid Requate univentionstaff 2018-10-08 19:37:08 CEST
Ok, cool, it works.

What ist the reason for you to change Simple_AD_Connection to directly use ReconnectLDAPObject instead of univention.uldap.access? I think we should keep the classes 'ad' and 'Simple_AD_Connection' as closely related as possible, to simplify maintenance. Anyway, the new code improves exception handling and is pretty readable, so there are also positive sides to your approach. Also, the consolidation of the classes into the new 'Simple_AD_Connection' is good.

Advisory: Ok
Comment 8 Arvid Requate univentionstaff 2018-10-10 12:31:39 CEST
<http://errata.software-univention.de/ucs/4.3/265.html>