root@dc1:~# ls -la /etc/ldap.secret
-rw-r----- 1 root DC Backup Hosts 20 Jun 27 2016 /etc/ldap.secret
Administrator is part of DC Backup Hosts.
(image not available)
root@dc1:~# ls -la /etc/ldap.secret
-rw-r----- 1 root DC Backup Hosts 20 Jun 27 2016 /etc/ldap.secret
Administrator is part of DC Backup Hosts.
(image not available)
So I did a chmod o+r on ldap.secret and machine.secret and a domain connect worked.
After the connect, I removed (o-r) on the two files. We'll see where it goes from here.
I'm sure it's not the right solution. There's obviously something wrong, but I seem to be up and running.
I'm glad you have your system joined. But yes, changing the file permissions in a way that anyone can read them is only a workaround - and must be reverted afterwards.
But this also proves that the permissions are the problem after all. I'm still wondering why it fails for Administrator. I remember a case, where there were inconsistencies regarding group membership. It looked as if the users were part of the group, but in fact they were not.
Could you please check two other points:
id Administrator
This will give you a list of IDs and displays the "real and effective user and group IDs" as the man page of id
states.
We should also have a closer look at the relevant group itself:
univention-ldapsearch -LLLo ldif-wrap=no cn='DC Backup Hosts'
Sorry for the delay…
root@dc1:~# id Administrator
uid=2002(Administrator) gid=5000(Domain Admins) groups=5000(Domain Admins),5001(Domain Users),1005(Windows Hosts),5005(DC Backup Hosts),5006(DC Slave Hosts),5007(Computers),5010(Authenticated Users),5015(Enterprise Domain Controllers),5044(Schema Admins),5045(Enterprise Admins),5046(Group Policy Creator Owners),5050(Denied RODC Password Replication Group),5051(Administrators),5052(Users)
root@dc1:~# univention-ldapsearch -LLLo ldif-wrap=no cn='DC Backup Hosts'
dn: cn=DC Backup Hosts,cn=groups,dc=erlphase,dc=com
objectClass: top
objectClass: posixGroup
objectClass: univentionGroup
objectClass: sambaGroupMapping
objectClass: univentionObject
objectClass: univentionPolicyReference
univentionObjectType: groups/group
univentionGroupType: -2147483646
cn: DC Backup Hosts
sambaGroupType: 2
gidNumber: 5005
uniqueMember: cn=dc1,cn=dc,cn=computers,dc=erlphase,dc=com
uniqueMember: uid=Administrator,cn=users,dc=erlphase,dc=com
uniqueMember: uid=join-backup,cn=users,dc=erlphase,dc=com
memberUid: dc1$
memberUid: Administrator
memberUid: join-backup
univentionPolicyReference: cn=default-backup-umc,cn=UMC,cn=policies,dc=erlphase,dc=com
sambaSID: S-1-5-21-203513847-2525019516-2689144297-1105
Thank you!
root@dc1:~# id Administrator
[...]5005(DC Backup Hosts)[...]
root@dc1:~# univention-ldapsearch -LLLo ldif-wrap=no cn='DC Backup Hosts'
dn: cn=DC Backup Hosts,cn=groups,dc=erlphase,dc=com
[...]
uniqueMember: uid=Administrator,cn=users,dc=erlphase,dc=com
[...]
memberUid: Administrator
[...]
that looks just fine. I’m really puzzled. This is becoming some enervating trial and error … with the lack of better ideas, I would create a new user, add them to “Domain Admis” and “DC Backup Hosts” and try the command /usr/sbin/udm users/user list
with this user again and see if that changes anything.