Univention Bugzilla – Bug 47901
AD Member setup fails if Active Driectory LDAP data signing is configured to "Require signature"
Last modified: 2018-10-10 12:31:39 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
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.
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.
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.
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
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
<http://errata.software-univention.de/ucs/4.3/265.html>