Hide Forgot
+++ This bug was initially created as a clone of Bug #923879 +++ Description of problem: When FreeIPA is configured with AD trust support, Kerberos tickets may also contain PAC which makes them bigger than usually expected (bigger than 2048 B) - 389-ds-base SASL layer does not accept that. # ipa-adtrust-install ... [11/19]: activating sidgen plugin and task [12/19]: activating extdom plugin [13/19]: configuring smbd to start on boot [14/19]: adding special DNS service records Unexpected error - see /var/log/ipaserver-install.log for details: NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-F19-AD-TEST.socket': # service dirsrv@F19-AD-TEST status Redirecting to /bin/systemctl status dirsrv@F19-AD-TEST.service dirsrv@F19-AD-TEST.service - 389 Directory Server F19-AD-TEST. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled) Active: active (running) since Wed 2013-03-20 15:54:11 CET; 47min ago Main PID: 16664 (ns-slapd) CGroup: name=systemd:/system/dirsrv@.service/F19-AD-TEST └─16664 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-F19-AD-TEST -i /var/run/dirsrv/slap... Mar 20 16:07:23 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 1 Mar 20 16:07:23 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 2 Mar 20 16:07:23 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 3 Mar 20 16:41:26 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 1 Mar 20 16:41:26 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 2 Mar 20 16:41:26 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 3 Mar 20 16:41:29 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 1 Mar 20 16:41:29 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 2 Mar 20 16:41:29 ipa.f19.ad.test ns-slapd[16664]: GSSAPI server step 3 Mar 20 16:41:30 ipa.f19.ad.test ns-slapd[16664]: encoded packet size too big (3014 > 2048) /var/log/dirsrv/slapd-F19-AD-TEST/errors: [20/Mar/2013:15:54:10 +0100] - slapd stopped. [20/Mar/2013:15:54:11 +0100] - 389-Directory/1.3.0.4 B2013.072.1657 starting up [20/Mar/2013:15:54:11 +0100] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=f19,dc=ad,dc=test [20/Mar/2013:15:54:11 +0100] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=f19,dc=ad,dc=test [20/Mar/2013:15:54:11 +0100] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=f19,dc=ad,dc=test [20/Mar/2013:15:54:11 +0100] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=f19,dc=ad,dc=test--no CoS Templates found, which should be added before the CoS Definition. [20/Mar/2013:15:54:12 +0100] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=f19,dc=ad,dc=test--no CoS Templates found, which should be added before the CoS Definition. [20/Mar/2013:15:54:12 +0100] - slapd started. Listening on All Interfaces port 389 for LDAP requests [20/Mar/2013:15:54:12 +0100] - Listening on All Interfaces port 636 for LDAPS requests [20/Mar/2013:15:54:12 +0100] - Listening on /var/run/slapd-F19-AD-TEST.socket for LDAPI requests [20/Mar/2013:16:41:29 +0100] - sasl_io_recv failed to decode packet for connection 23 This section in the 389-ds-base source code looks to be blamed: $ find -type f | xargs grep -C 5 maxbufsize ./ldap/servers/slapd/saslbind.c- prop_request(propctx, dn_propnames); ./ldap/servers/slapd/saslbind.c- } ./ldap/servers/slapd/saslbind.c- } ./ldap/servers/slapd/saslbind.c- ./ldap/servers/slapd/saslbind.c- /* Enable security for this connection */ ./ldap/servers/slapd/saslbind.c: secprops.maxbufsize = 2048; /* DBDB: hack */ ./ldap/servers/slapd/saslbind.c- secprops.max_ssf = 0xffffffff; ./ldap/servers/slapd/saslbind.c- secprops.min_ssf = config_get_minssf(); ./ldap/servers/slapd/saslbind.c- /* If anonymous access is disabled, set the appropriate flag */ ./ldap/servers/slapd/saslbind.c- if (config_get_anon_access_switch() != SLAPD_ANON_ACCESS_ON) { ./ldap/servers/slapd/saslbind.c- secprops.security_flags = SASL_SEC_NOANONYMOUS; Version-Release number of selected component (if applicable): 389-ds-base-1.3.0.4-1.fc19.x86_64 How reproducible: Steps to Reproduce: 1. Install freeipa-* packages 2. Run ipa-server-install 3. Run ipa-adtrust-install Actual results: ipa-adtrust-install crashes due to issue described above. Expected results: 389-ds-base accepts tickets with PAC and installer does not crash. Additional info: --- Additional comment from Martin Kosek on 2013-03-20 13:00:55 EDT --- I just verified that by increasing this value, FreeIPA fixes too.
Upstream ticket: https://fedorahosted.org/389/ticket/632
Created attachment 733920 [details] git patch file 1 Bug Description: When FreeIPA is configured with AD trust support, Kerberos tickets may also contain PAC which makes them bigger than usually expected (bigger than 2048 B) Fix Description: Make the default 64k(65536), and allow it to be configurable using: nsslapd-sasl-max-buffer-size https://fedorahosted.org/389/ticket/632
Created attachment 733921 [details] git patch file 2 Bug Description: After upgrading the server fails to start because the Root DN access control plugin's entry changed to include nsslapd-Plugin objectclass. Fix Description: Update the schema to allow nsslapd-plugin-depends-on-type in the nsslapdPlugin objectclass.
This bug opened during FreeIPA Test day seems related, but he hasn't configured trust: https://bugzilla.redhat.com/show_bug.cgi?id=953653
Please, add verification steps (for tet) - or will this be automated in FreeIPA ?
We do not automate it in FreeIPA, we did not have issue with it in RHEL. In Fedora 19, the reproduction was simple: # yum install ipa-server ipa-server-trust-ad # ipa-server-install ... follow wizard to configure IPA server # ipa-adtrust-install ... crashed during the middle due to this buffer limitation (see Steps to reproduce bove)
Mark, were you able to reproduce this issue outside of IPA?
No, I was not able to.
Testcase in schema/runschema.
[jrusnack@dstet schema]$ grep "nsslapdPlugin" 01core389.ldif objectClasses: ( 2.16.840.1.113730.3.2.41 NAME 'nsslapdPlugin' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ nsslapd-pluginPath $ nsslapd-pluginInitFunc $ nsslapd-pluginType $ nsslapd-pluginId $ nsslapd-pluginVersion $ nsslapd-pluginVendor $ nsslapd-pluginDescription $ nsslapd-pluginEnabled ) MAY ( nsslapd-pluginConfigArea ) X-ORIGIN 'Netscape Directory Server' ) [jrusnack@dstet schema]$ rpm -qa | grep 389 389-ds-base-debuginfo-1.2.11.15-22.el6.x86_64 389-ds-base-1.2.11.15-22.el6.x86_64 389-ds-base-libs-1.2.11.15-22.el6.x86_64 Tests failed - nsslapdPlugin does not contain nsslapd-plugin-depends-on-type. Hence putting back to ASSIGNED.
[root@hp-dl380pgen8-02-vm-15 schema]# grep "nsslapdPlugin" 01core389.ldif objectClasses: ( 2.16.840.1.113730.3.2.41 NAME 'nsslapdPlugin' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ nsslapd-pluginPath $ nsslapd-pluginInitFunc $ nsslapd-pluginType $ nsslapd-pluginId $ nsslapd-pluginVersion $ nsslapd-pluginVendor $ nsslapd-pluginDescription $ nsslapd-pluginEnabled ) MAY ( nsslapd-pluginConfigArea $ nsslapd-plugin-depends-on-type ) X-ORIGIN 'Netscape Directory Server' ) [root@hp-dl380pgen8-02-vm-15 schema]# rpm -qa 389-ds-base 389-ds-base-1.2.11.15-23.el6.i686 The latest build shows that the attribute "nsslapd-plugin-depends-on-type" exists in the schema. So, you can go ahead and flip the bugzilla back to Verified state.
Marking verified as per comment https://bugzilla.redhat.com/show_bug.cgi?id=923909#c17
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1653.html