Using Fedora 13 (i686) with updates applied and samba4 compiled from the git master. [root@fed samba]# rpm -qa | grep 389 389-ds-base-1.2.6-0.1.a1.fc13.i686 Samba's smb.conf a'la http://freeipa.org/page/Samba_4_Configuration [root@fed samba]# ./sbin/provision --server-role="domain controller" \ --domain="TEST" --realm=AD.TEST.LOCAL \ --ldap-backend-type=fedora-ds \ --root=root --adminpass=Secret123 --ldapadminpass=Secret123 \ --host-name=ad --host-ip=127.0.0.1 \ --slapd-path=/usr/sbin/ns-slapd --setup-ds-path=/usr/sbin/setup-ds.pl Converted 58 records with 0 failures Warning: using root as the server user id. You are strongly encouraged to use a non-root user. Your new DS instance 'ad' was successfully created. Exiting . . . Log file is '/tmp/setupges4Nz.log' importing data ... [21/Jun/2010:22:41:17 +0100] - Information: Non-Secure Port Disabled [21/Jun/2010:22:41:17 +0100] - Backend Instance: sambaData [21/Jun/2010:22:41:18 +0100] - dblayer_instance_start: pagesize: 4096, pages: 305246, procpages: 9720 [21/Jun/2010:22:41:18 +0100] - cache autosizing: import cache: 204800k [21/Jun/2010:22:41:18 +0100] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [21/Jun/2010:22:41:18 +0100] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [21/Jun/2010:22:41:18 +0100] - dblayer_instance_start: pagesize: 4096, pages: 305246, procpages: 9720 [21/Jun/2010:22:41:18 +0100] - cache autosizing: import cache: 204800k [21/Jun/2010:22:41:18 +0100] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [21/Jun/2010:22:41:18 +0100] - import sambaData: Beginning import job... [21/Jun/2010:22:41:18 +0100] - import sambaData: Index buffering enabled with bucket size 100 [21/Jun/2010:22:41:18 +0100] - import sambaData: Processing file "/usr/local/samba/private/ldap/fedorads-samba.ldif" [21/Jun/2010:22:41:18 +0100] - import sambaData: Finished scanning file "/usr/local/samba/private/ldap/fedorads-samba.ldif" (4 entries) [21/Jun/2010:22:41:19 +0100] - import sambaData: Workers finished; cleaning up... [21/Jun/2010:22:41:19 +0100] - import sambaData: Workers cleaned up. [21/Jun/2010:22:41:19 +0100] - import sambaData: Cleaning up producer thread... [21/Jun/2010:22:41:19 +0100] - import sambaData: Indexing complete. Post-processing... [21/Jun/2010:22:41:19 +0100] - import sambaData: Flushing caches... [21/Jun/2010:22:41:19 +0100] - import sambaData: Closing files... [21/Jun/2010:22:41:20 +0100] - All database threads now stopped [21/Jun/2010:22:41:20 +0100] - import sambaData: Import complete. Processed 4 entries in 2 seconds. (2.00 entries/sec) Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' [21/Jun/2010:22:41:20 +0100] - Information: Non-Secure Port Disabled [21/Jun/2010:22:41:20 +0100] - 389-Directory/1.2.6.a1 B2010.025.182 starting up Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' [21/Jun/2010:22:41:21 +0100] - I'm resizing my cache now...cache was 209715200 and is now 8000000 Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' [21/Jun/2010:22:41:23 +0100] - Listening on /usr/local/samba/private/ldap/ldapi for LDAPI requests Setting up secrets.ldb Setting up the registry Setting up the privileges database Setting up idmap db Setting up SAM db Setting up sam.ldb partitions and settings Setting up sam.ldb rootDSE Pre-loading the Samba 4 and AD schema Adding DomainDN: DC=ad,DC=test,DC=local pdc_fsmo_init: no domain object present: (skip loading of domain details) Traceback (most recent call last): File "./sbin/provision", line 256, in <module> useeadb=eadb) File "/usr/local/samba/lib/python2.6/site-packages/samba/provision.py", line 1433, in provision dom_for_fun_level=dom_for_fun_level, am_rodc=am_rodc) File "/usr/local/samba/lib/python2.6/site-packages/samba/provision.py", line 1025, in setup_samdb "DESCRIPTOR": descr File "/usr/local/samba/lib/python2.6/site-packages/samba/provision.py", line 345, in setup_add_ldif ldb.add_ldif(data, controls) File "/usr/local/samba/lib/python2.6/site-packages/samba/__init__.py", line 217, in add_ldif self.add(msg,controls) _ldb.LdbError: (1, 'Operations error (1)') It seems to me, that it is trying to bind before 389-ds actually started listening on the socket. Although this issue shows similarities to bug #7040 - the patches for bug #7040 have been incorporated into the git tree.
Hi Attila, I've been investigating this issue. The bind failure that you see is not a problem, it's the provisioning tool trying to see if the backend server is running. The real problem is with the operations error you see at the bottom. It is caused by several things. This is what I found so far: 1. The ldb_msg_el_map_remote() does not rename the remote attribute names into local names as defined in simple_ldap_map.c. I will submit a patch for this. 2. There is an attribute type definition missing from the FDS's core schema. See https://bugzilla.redhat.com/show_bug.cgi?id=606545. A patch is already provided. With the above problems fixed, the provisioning works fine, but there is still a problem running Samba with FDS backend which I'm still investigating.
Created attachment 5804 [details] 0001-s4-ldb-ldb_msg_el_map_remote-should-rename-the-remot.patch This patch fixes problem #1 described earlier. The ldb_msg_el_merge_wildcard() is using ldb_msg_el_map_remote() to copy all remote attributes and hoping that they will be overwritten by more specific rules later on. The problem is ldb_msg_el_map_remote() will use the remote attribute name. The function has been fixed so it will search and use the local attribute name as defined in simple_ldap_map.c.
Comment on attachment 5804 [details] 0001-s4-ldb-ldb_msg_el_map_remote-should-rename-the-remot.patch Endi, thanks for the patch, it is applied. Please tell us when also the other issue has been fixed - so I can close the bug
(In reply to comment #3) > > Please tell us when also the other issue has been fixed - so I can close the > bug BTW, I've also tested with OpenLDAP backend on Fedora13. The quicktest is failing. Will test with the patch included.
Created attachment 5809 [details] 0001-s4-auth-Fixed-authsam_expand_nested_groups-to-find-e.patch When an LDAP server is used as a backend, the DN in the memberOf attribute will not contain SID, so authsam_expand_nested_groups() will fail. The function has been fixed to perform dsdb_search to find the SID if it's not present in the DN.
Created attachment 5810 [details] 0001-s4-dsdb-Fixed-partition_search-not-to-pass-special-D.patch Some special DN's such as @REPLCHANGED are being passed to the LDAP backend creating some problems. These DN's should only be handled by the main partition.
Created attachment 5811 [details] 0001-s4-spnupdate-Fixed-spnupdate-to-use-secrets-credenti.patch The samba_spnupdate needs to use the credentials from the secrets database to access SamDB.
Created attachment 5812 [details] 0001-s4-libcli-Register-LDB_CONTROL_REVEAL_INTERNALS-and-.patch The LDB_CONTROL_REVEAL_INTERNALS and DSDB_CONTROL_PASSWORD_CHANGE_STATUS_OID controls need to be registered.
Endi, can I mark this as "FIXED"?
As mentioned on the list, this will need to be reworked. The auth and dsdb patches are wrong: The partitions patch will, as I read it, totally break replication, as it will remove the search for @REPLCHANGED from being propagated down to each backend database. (so we know if a particular database needs replication) The expand_nested_groups patch will work, but I do not wish us to take this approach. The LDAP backend needs to provide, one way or another, this information - if we start to have fallbacks in the code, we will duplicate the whole extended DN infrastructure in each caller. The OpenLDAP backend provides this by a server-side module, and either Fedora DS must do the same, or fake it up in a Samba module at the bottom of the stack.
How to proceed here?
I think this has been fixed. If not, please reopen!