Univention Bugzilla – Bug 31443
Singlemaster: windows client objects created at wrong position
Last modified: 2013-11-14 09:24:37 CET
If windows clients get joined on a single master, their computer objects are created in cn=computers,$ldap_base if the computer objects have not been created before. Since the windows clients objects are not within the OU-subtree of the specific school the computers cannot be assigned to a computer room. → on a single master new windows clients should be created below the standard OU if automatically created via samba.
*** Bug 31620 has been marked as a duplicate of this bug. ***
From Bug 31620: > Probably one could make the ldb module from libunivention-ldb-modules usable > also for the singlemaster scenario, to use it to create the windows-clients in > the proper location.
The UMC command selectiveudm/create_windows_computer expects to derive the OU from the DN of the machine account that initiates the operation. On a ucs-school-singlemaster this currently fails since the UCS@school DC Master account is not moved below the OU during join. If I move the DC account below the OU and adjust some UMC-ACL, the operation works as expected. UCS@school DCs can host multiple OUs though, so this approach probably does not cut it for all cases. Something probably needs to be adjusted in univention-management-console-module-selective-udm for this. A different approach would be to make the ldb-module pass the credentials of the administrative user who performs the join. But first I don't know if/how we can access these credentials in the module and second it would make simple join via "Administrator" impossible.
(In reply to Arvid Requate from comment #3) > The UMC command selectiveudm/create_windows_computer expects to derive the > OU from the DN of the machine account that initiates the operation. On a > ucs-school-singlemaster this currently fails since the UCS@school DC Master > account is not moved below the OU during join. If I move the DC account > below the OU and adjust some UMC-ACL, the operation works as expected. Could we define a fallback OU via UCR? univention-management-console-module-selective-udm can use this OU if the DC is not below an OU. Or the module uses the first OU.
* ucs-school-singlemaster now depends on libunivention-ldb-modules. * The new preinst of ucs-school-singlemaster now sets samba4/ldb/sam/module/prepend so this is set before libunivention-ldb-modules.postinst runs the joinscripts on a master. * libunivention-ldb-modules now correctly executes the three joinscripts from its postinst * 98univention-samba4slavepdc-dns.inst exits 1 if 98univention-samba4-dns.inst has not been executed yet (just cosmetics currently, to avoid error messages in the log) * UMC module selective-udm was adjusted to use the python-ucs-school library functions to detect the OU. In its standard configuration it derives the OU from the binddn. If this is not possible (as in ucs-school-singlemaster), it picks the first OU found in LDAP. The library also allows manual specification of the OUs to be considered and their sort order via UCR ucsschool/local/oulist.
No YAML file yet. Changelog: changelog-ucsschool-3.1R3.tex The changelog points out that the following command needs to be run manually once on updated systems: umc_policy_append "default-backup-umc" "selective-udm"
(In reply to Arvid Requate from comment #6) > The changelog points out that the following command needs to be run manually > once on updated systems: umc_policy_append "default-backup-umc" > "selective-udm" Why not increasing the join script version number and fixing it within the join script? (In reply to Arvid Requate from comment #5) > * ucs-school-singlemaster now depends on libunivention-ldb-modules. > > * The new preinst of ucs-school-singlemaster now sets > samba4/ldb/sam/module/prepend so this is set before > libunivention-ldb-modules.postinst runs the joinscripts on a master. Are there any additional steps necessary if a single server environment gets converted to a multi server environment? Please check the UCS@school admin manual.
Ok, in this case increasing the joinscript version during an errata seems reasonable. Conversion to a multi server environement is not affected. Note: Bug 31936 should be fixed to cover all Samba 4 installation scenarios in UCS@school.
(In reply to Arvid Requate from comment #8) > Ok, in this case increasing the joinscript version during an errata seems > reasonable. After updating a single master environment, I'm not able to join a windows 7 client: Ein an das System angeschlosses Gerät funktioniert nicht. From the S4 logfile: 2013/07/12 09:00:32.351487, 0, pid=21968] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: WARNING: Module [univention_samaccountname_ldap_check] not found - do you need to set LDB_MODULES_PATH? [2013/07/12 09:00:32.351907, 0, pid=21968] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: Unable to load modules for /var/lib/samba/private/sam.ldb: (null) [2013/07/12 09:00:32.414309, 0, pid=21968] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: WARNING: Module [univention_samaccountname_ldap_check] not found - do you need to set LDB_MODULES_PATH? [2013/07/12 09:00:32.414754, 0, pid=21968] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: Unable to load modules for /var/lib/samba/private/sam.ldb: (null)
I guess univention-s4search doesn't work either in this case? Worked for me with version 1.0.5-5.44.201307121203 of libunivention-ldb-modules installed on ucs3.1-1. I installed the singlemaster via wizard and then did a univention-install libunivention-ldb-modules univention-s4-connector
A samba4 restart was missing. Fixed.
Changelog: OK New installed single env: OK Updated single env: OK New installed multi env: OK Updated multi env: OK
UCS@school 3.1 R2-1 has been released: http://download.univention.de/doc/release-notes-ucsschool-3.1-rev2-1.pdf If this error occurs again, please use "Clone This Bug".