Univention Bugzilla – Bug 51833
Drop requirement for join user to be part of group "DC Backup Hosts"
Last modified: 2020-11-20 18:17:18 CET
It would be great, if during a join the ldap.secret and ldap-backup.secret would be copied using the Host account. That way, the joining user would not need to have read access to these files on the master
(In reply to Kevin Dominik Korte from comment #0) > It would be great, if during a join the ldap.secret and ldap-backup.secret > would be copied using the Host account. That way, the joining user would not > need to have read access to these files on the master I don't understand the request right now. /etc/ldap.secret and /etc/ldap-backup.secret can be read by the DC Backup Hosts group. This group contains DC Master and the DC Backups. More computer objects should not be able to read these credentials either, otherwise the whole domain can be taken over. What is the goal of your request?
right now the files are copied from the master using the account given during the join. Thus one is required to add the user to the DC Backup Host group to enable him to copy the files. As the machine account is already populated at that point, it could be used. The goal is to simplify the permissions needed for the join
(In reply to Kevin Dominik Korte from comment #2) > right now the files are copied from the master using the account given > during the join. No, /etc/ldap.secret is not copied. Maybe this is done only in the customer scope? Or are you speaking about /etc/machine.secret?
Line 836 on my System (UCS 4.4-5 DC Backup without customer modifications) says: univention-scp "$DCPWD" -q "${DCACCOUNT}@${DCNAME}:/etc/ldap.secret" /etc/ldap.secret >>/var/log/univention/join.log 2>&1 Doing a grep for univention-scp shows a number of additional places. /etc/machine.secret isn't copied and probably the only action, that would need to be taken by the Joining User. As by definition the host doesn't have a host account yet.
See <https://docs.software-univention.de/developer-reference-4.4.html#join:secret> for the current documentation, also the out-commented blocks in doc/developer-reference/ldap/ldap.xml, Bug #47455 to improve the documentation about those /etc/*.secret files, and Bug #31252 to remove several old files no longer used. As I have to explain those files in each UCS Technical Training here my summary: - /etc/machine.secret - /etc/libnss-ldap.secret - /etc/pam_ldap.secret per host on every UCS host (and UCC/Ubuntu client?) password for host account (UCRV ldap/hostdn) initially setup during domain join using updates regularly by server-password-change used by many tools to get at least read-permissions and limited write permissions for host account. - /etc/ldap.secret per domain for "cn=admin,$ldap_base" (LDAP Admin) only on Master and Backups NEVER changed! → if ever leaked infinite read/write access to ALL data → no mechanism to change it → should be changed manually if any administrator with join privileges leaves company to protect against later mis-use! used by many tools to gain automatic write access to LDAP, e.g. running UDM on Master/Backups, e.g. during domain join of OTHER systems - /etc/ldap-backup.secret per domain for "cn=backup,$ldap_base" only Master, Backups, Slaves NEVER changed! ? used for "idmap config v6 for Samba 3.6.0" - /etc/backup-join.secret for account "uid=join-backup,cn=users,$ldap_base" ? used by services/univention-samba/26univention-samba.inst to join the Samba DC - /etc/slave-join.secret for account "uid=join-slave,cn=users,$ldap_base" ? unused (as of UCS-4) - /etc/idp-ldap-user.secret - /etc/listfilter.secret (In reply to Kevin Dominik Korte from comment #4) > Line 836 on my System (UCS 4.4-5 DC Backup without customer modifications) > says: > > univention-scp "$DCPWD" -q "${DCACCOUNT}@${DCNAME}:/etc/ldap.secret" > /etc/ldap.secret >>/var/log/univention/join.log 2>&1 > > Doing a grep for univention-scp shows a number of additional places. The code is ONLY executed on DC Backups as the file exists only on the Master and Backups. > /etc/machine.secret isn't copied and probably the only action, that would > need to be taken by the Joining User. As by definition the host doesn't have > a host account yet. As /etc/machine.secret is "per host", copying it between hosts is NEVER right. It also is NOT done: the current process is that "univention-join" - logs into the Master with the given credentials to call "univention-server-join" there, which - creates the INITIAL machine secret on the Master - calls UDM there to create the new machine account - returns the DN and the initial credentials - parses those values from the return text stream. - ONLY for Backups "univention-join" the re-logins to the Master again to download the "ldap.secret" and "ldap-backup.secret" already using the newly created MACHINE account, which works as Backups are member of group "cn=DC Backup Hosts", which have read-access to those files. (In reply to Kevin Dominik Korte from comment #0) > It would be great, if during a join the ldap.secret and ldap-backup.secret > would be copied using the Host account. This is already the case - see paragraph directly above. > That way, the joining user would not need to have read access to these files on the master See Bug #47193 for the original change to the documentation <https://docs.software-univention.de/manual-4.4.html#domain-ldap:Subsequent_domain_joins_with_univention-join>. If you specify the join user and credentials on the command line like this univention-join -dcname m34.phahn.dev -dcaccount phahn -dcpwd <(echo -n univention) -verbose it first seems to work, but later fails when copying /var/lib/univention-ldap/notify/transaction in /usr/sbin/univention-join::234 as the code there assumes that the join used has permissions to read that file: The code there wrongly(?) assumes that the join user is member of "DC Backup Hosts", which is the group of that file. diff --git a/management/univention-join/univention-join b/management/univention-join/univention-join index f946a83e81..a5670edbea 100755 --- a/management/univention-join/univention-join +++ b/management/univention-join/univention-join @@ -141,7 +141,7 @@ copy_ca_cert () { for ca in ucsCA udsCA do [ -e "$dst/CAcert.pem" ] && break - univention-scp "$DCPWD" -q "${DCACCOUNT}@${DCNAME}:/etc/univention/ssl/${ca}/CAcert.pem" "$dst/CAcert.pem" + univention-scp /etc/machine.secret -q "${hostname}\$@${DCNAME}:/etc/univention/ssl/${ca}/CAcert.pem" "$dst/CAcert.pem" done } >>/var/log/univention/join.log 2>&1 grep -q '^TLS_CACERT' /etc/ldap/ldap.conf || echo "TLS_CACERT /etc/univention/ssl/ucsCA/CAcert.pem" >>/etc/ldap/ldap.conf @@ -231,8 +231,8 @@ run_join_scripts () { # backup if [ "$server_role" = "domaincontroller_backup" ]; then - univention-scp "$DCPWD" -r \ - "${DCACCOUNT}@${DCNAME}:/var/lib/univention-ldap/notify/transaction" \ + univention-scp /etc/machine.secret -r \ + "${hostname}\$@${DCNAME}:/var/lib/univention-ldap/notify/transaction" \ "$USERTMP/tlog" >/dev/null 2>&1 if [ ! -e "$USERTMP/tlog" ]; then failed_message " FAILED: failed to copy /var/lib/univention-ldap/notify/transaction from the dc master. Please try again." @@ -253,8 +253,8 @@ run_join_scripts () { # slave if [ "$server_role" = "domaincontroller_slave" ]; then if [ -n "$listener_supply_notifier" -a "$listener_supply_notifier" = "yes" ]; then - univention-scp "$DCPWD" -q \ - "${DCACCOUNT}@${DCNAME}:/var/lib/univention-ldap/notify/transaction" \ + univention-scp /etc/machine.secret -q \ + "${hostname}\$@${DCNAME}:/var/lib/univention-ldap/notify/transaction" \ "$USERTMP/tlog" >/dev/null 2>&1 id="$(</var/lib/univention-directory-listener/notifier_id)" awk -F ' ' '{ if ( $1 <= '$id') print }' "$USERTMP/tlog" >/var/lib/univention-ldap/notify/transaction Later on 96univention-samba4.inst still fails to join Samba: > samba-tool domain join phahn.dev DC --server m34 --kerberos=no -Uphahn%univention --realm=PHAHN.DEV --machinepass=v8VxneOyGWnWBCpmrTIb > ldb_init_module() in ../../source4/dsdb/samdb/ldb_modules/password_hash.c version[1.5.8]: gpgme_check_version(1.12.0) not available, > gpgme_check_version(NULL) => '1.8.0' > ldb: failed to initialise module /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/samba/password_hash.so : Unavailable > ldb: failed to initialise module /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/samba : Unavailable > ERROR(<class 'MemoryError'>): uncaught exception - > File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line 185, in _run > return self.run(*args, **kwargs) > File "/usr/lib/python3/dist-packages/samba/netcmd/domain.py", line 699, in run > backend_store=backend_store) > File "/usr/lib/python3/dist-packages/samba/join.py", line 1516, in join_DC > backend_store=backend_store) > File "/usr/lib/python3/dist-packages/samba/join.py", line 108, in __init__ > credentials=ctx.creds, lp=ctx.lp) I have not checked on how to fix that - maybe see <https://help.univention.com/t/delegating-right-to-join-windows-clients-in-samba-4-domains/6450>.
Permissions to join systems into the UCS domain can be granted to other users by giving them access to group "Domain Admins" and "DC Backup Hosts". The last one gives you unlimited access forever as you then can copy /etc/ldap.secret, which is NEVER changed. This is annoying is remote scenarios where an otherwise un-trusted user must re-join some system. In that case a "one-time token" would be much useful. TT 2020-11-19/20