Can't login Administrator after install

Hello!
I’m installed today UCS 5.0-1 errata176 version on Proxmox VE from downloaded ISO file
After install and Create new UCS domain, try login WebUI with login root - fine, login successful.
When login with Administrator - error, with message The authentication has failed, please login again.

Reinstall UCS not helped(
Help!

This bug is very strange…

UPD: Also, when install in VirtualBox all ok, login without troubles

Dec 17 17:56:11 unassigned-hostname python3: pam_unix(univention-management-console:auth): check pass; user unknown
Dec 17 17:56:11 unassigned-hostname python3: pam_unix(univention-management-console:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Dec 17 17:56:11 unassigned-hostname python3: pam_krb5(univention-management-console:auth): authentication failure; logname=Administrator uid=0 euid=0 tty= ruser= rhost=

In /var/log/auth.log

Did you solved your problem ?
cause I have a similar one
ssh Administrator@localhost is not working anymore

root@dcm:~# ssh Administrator@localhost
Password:
Password:
Password:
Administrator@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive).
root@dcm:~# tail /var/log/auth.log
Dec 20 22:27:38 dcm sshd[4368]: error: PAM: Authentication failure for illegal user Administrator from ::1
Dec 20 22:27:38 dcm sshd[4368]: Failed keyboard-interactive/pam for invalid user Administrator from ::1 port 47798 ssh2
Dec 20 22:27:38 dcm sshd[4368]: Postponed keyboard-interactive for invalid user Administrator from ::1 port 47798 ssh2 [preauth]
Dec 20 22:27:41 dcm sshd[4384]: pam_krb5(sshd:auth): authentication failure; logname=Administrator uid=0 euid=0 tty=ssh ruser= rhost=::1
Dec 20 22:27:41 dcm sshd[4384]: pam_unix(sshd:auth): check pass; user unknown
Dec 20 22:27:41 dcm sshd[4384]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1
Dec 20 22:27:41 dcm sshd[4384]: pam_ldap: error trying to bind (Strong(er) authentication required)
Dec 20 22:27:43 dcm sshd[4368]: error: PAM: Authentication failure for illegal user Administrator from ::1
Dec 20 22:27:43 dcm sshd[4368]: Failed keyboard-interactive/pam for invalid user Administrator from ::1 port 47798 ssh2
Dec 20 22:27:43 dcm sshd[4368]: Connection closed by invalid user Administrator ::1 port 47798 [preauth]

Please check that the user Administrator in known by running the command

$ id Administrator
uid=2002(Administrator) gid=5000(Domain Admins) Gruppen=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),5045(Schema Admins),5046(Enterprise Admins),5047(Group Policy Creator Owners),5051(Denied RODC Password Replication Group),5052(Administrators),5053(Users)

If you get id: ‘Administrator2’: no such user instead the PAM is unable to talk to LDAP.

Check that the user entry exists in LDAP by running the command:

$ univention-ldapsearch -LLL uid=Administrator createTimestamp modifyTimestamp 
dn: uid=Administrator,cn=users,dc=qa50,dc=pmh
createTimestamp: 20210615083442Z
modifyTimestamp: 20211220123658Z

If the user exists try to authenticate explicitly as that user to verify the password matches:

$ ldapsearch -x -D "uid=Administrator,cn=users,$(ucr get ldap/base)" -w 'YOUR_PASSWORD' uid=Administrator 1.1

Also try to authenticate using Kerberos:

$ kinit Administrator

Last check the join status by running:

$ univention-check-join-status 
Joined successfully

If you get a long list of join scripts instead please try to run univention-run-join-scripts.

HI pmhan

Thanks for your answer!
I tested all the above commands, they all came back successfully
the entry was found in ldap kerberos assigned a ticket …
but the group membership looks different could that be a reason for my issue ?
left=mine right=this from your post
image

The difference in group membership might be the cause as login is restricted to certain groups and users:
ucr search --brief --non-empty ^auth/sshd/

  • For ssh this is relevant as by default only members of group Administrators and Domain Admins are allowed.
  • For UMC there are no such restrictions via UCR by default; the list of available UMC modules per user is handled UDM settings/umc_operationset.

Can you please run the following command when logged in as user root:
LC_ALL=C.UTF-8 su -s /bin/sh -c 'id Administrator' nobody
It it returns id: ‘Administrator’: no such user check the status us nscd by running the following command:
systemctl status nscd.service
Try (re-)starting it by running the command
systemctl restart nscd.service
PS: nscd is required as /etc/machine.secret is only readable for user root, but any user is supposed to use getent passwd. nscd runs as user root and thus caches that information for anybody to use. With sshd using priviledge separation nowadays this might explain why it is unable to lookup Administrator.

Dec 20 22:27:41 dcm sshd[4384]: pam_ldap: error trying to bind (Strong(er) authentication required)

That should not happen; I would check /etc/libnss-ldap.conf and /etc/ldap/ldap.conf and /etc/nsswitch.conf for any certificate settings to make sure slapd has a valid SSL/TLS certificate. Run this:
univention-certificate check -name $(hostname -f)
To me this looks like no encrypted LDAP connection using STARTTLS can be established and thus PAM failed to find the user.

looks okay to me…

root@dcsc:/mnt# ucr search --brief --non-empty ^auth/sshd/
auth/sshd/group/Administrators: yes
auth/sshd/group/Computers: yes
auth/sshd/group/DC Backup Hosts: yes
auth/sshd/group/DC Slave Hosts: yes
auth/sshd/group/Domain Admins: yes
auth/sshd/restrict: yes
auth/sshd/user/root: yes

also next

root@dcsc:/mnt# LC_ALL=C.UTF-8 su -s /bin/sh -c 'id Administrator' nobody
uid=2002(Administrator) gid=5000(Domain Admins) groups=5000(Domain Admins),5001(                                                                    Domain Users),5005(DC Backup Hosts),5046(Schema Admins),5047(Enterprise Admins),                                                                    5048(Group Policy Creator Owners),5053(Administrators)

the nscd service otherwise claims about one of my backup-DC’s

Jan 05 13:55:11 dcsc nscd[673]: nss-ldap: do_open: do_start_tls failed:stat=-1
Jan 05 13:55:11 dcsc nscd[673]: nss-ldap: do_open: do_start_tls failed:stat=-1
Jan 05 13:55:12 dcsc nscd[673]: nss_ldap: failed to bind to LDAP server ldap://TM01-DC02.office.firma.com:7389: Invalid credentials
Jan 05 13:55:12 dcsc nscd[673]: nss_ldap: reconnected to LDAP server ldap://dcsc.office.firma.com:7389 after 1 attempt
Jan 05 13:59:12 dcsc nscd[673]: 673 überwachte Datei »/etc/resolv.conf« wurde moved into place, füge Überwachung hinzu
Jan 05 13:59:42 dcsc nscd[673]: 673 überwachte Datei »/etc/resolv.conf« wurde moved into place, füge Überwachung hinzu
Jan 05 13:59:42 dcsc nscd[673]: 673 inotify Event für Datei »/etc/resolv.conf« ignoriert (Datei existiert)
Jan 05 20:52:32 dcsc nscd[673]: nss_ldap: reconnecting to LDAP server...
Jan 05 20:52:32 dcsc nscd[673]: nss_ldap: reconnected to LDAP server ldap://dcsc.office.firma.com:7389 after 1 attempt

my libnss-ldap.conf is a debian default one not the one generated by univention template …
which pkg is that? can I simply reinstall that ?

root@dcsc:/mnt# univention-certificate check -name $(hostname -f)
Certificate "dcsc.office.firma.com" with serial number 01 is invalid (revoked)
Certificate "dcsc.office.firma.com" with serial number 02 is valid
Certificate "dcsc.office.firma.com" with serial number 14 is invalid (revoked)

Would an

ucr commit /etc/libnss-ldap.conf

be the correct way ?

About /etc/libnss-ldap.conf

Try ucr commit /etc/libnss-ldap.conf to re-create that file from it’s template /etc/univention/templates/files/etc/libnss-ldap.conf, which is part of the package univention-pam. You can re-install it doing apt-get {--re,}install univention-pam if you accidentally removed some file.
That might fail for conf-files below /etc/ as dpkg will not restore them when you deleted them; in that case do something like this:

cd "${TMPDIR:-/tmp}"
apt-get download univention-pam
dpkg -x univention-pam_*_all.deb ./x/
cp ./x/etc/univention/templates/files/etc/libnss-ldap.conf /etc/univention/templates/files/etc/libnss-ldap.conf
rm -rf univention-pam_*_all.deb ./x

You should check why that file is not handled by UCR and if there are more files where our UCR template mechanism does not work. Are the packages univention-pam and univention-base-files still installed and configured correctly?
You can run ucr commit without any additional arguments to re-generate all files, which might disconnect you from the computer as this also triggers a network re-configuration.

About certificates

I’m a bit concerned that your last certificate 14 was revoked. As far as I know “certificate revocation lists” (crl) are not used in UCS, but please verify that your /etc/univention/ssl/$FQHN/cert.pem matches /etc/univention/ssl/ucsCA/certs/02.pem and not …/14.pem

You should also check why ldap://TM01-DC02.office.firma.com:7389 fails, e.g. which certificate it is using and if it is valid; both the following commands should work:

univention-ldapsearch -H ldap://TM01-DC02.office.firma.com:7389 -s base
univention-ldapsearch -H ldap://dcsc.office.firma.com:7389 -s base

Original problem

As sshd is using privilege separation, which makes debugging this harder, please try to switch the user using su this:
su -s /bin/bash -c 'su Administrator' nobody

For ssh and PAM verify your file permissions:

# ls -ld /etc/pam_ldap.conf /etc/pam_ldap.secret  /etc/machine.secret
-rw------- 1 root root  20 Jan  6 01:07 /etc/machine.secret
-rw-r--r-- 1 root root 583 Nov 18 11:28 /etc/pam_ldap.conf
lrwxrwxrwx 1 root root  19 Jun 15  2021 /etc/pam_ldap.secret -> /etc/machine.secret

Also verify the content of /etc/pam_ldap.conf (templated from /etc/univention/templates/files/etc/pam_ldap.conf): within uri and rootbinddn and base must be correct:

ldapsearch -LLLZZx \
  -H "$(sed -ne 's/^uri //p;T;q' /etc/pam_ldap.conf)" \
  -D "$(sed -ne 's/^rootbinddn //p;T;q' /etc/pam_ldap.conf)" \
  -y /etc/pam_ldap.secret \
  -b "$(sed -ne 's/^base //p;T;q' /etc/pam_ldap.conf)" \
  -s base

Again many thanks @pmhahn especially due to public holiday

the missing packages where reinstalled now the libnss-ldap.conf looks much better (configured by template)

all my univention-ldapsearch failed with
ldap_start_tls: Can’t contact LDAP server (-1)

the

root@dcsc:~# su -s /bin/bash -c 'su Administrator' nobody
Passwort:
bash: Kann die Prozessgruppe des Terminals nicht setzen (21370).: Unpassender IOCTL (I/O-Control) für das Gerät
bash: Keine Job Steuerung in dieser Shell.
Administrator@dcsc:/root$

is working…
the file permissions are set correctly

and the certs are valid

 openssl x509 -in /etc/univention/ssl/dcsc/cert.pem --issuer_hash --subject_hash -noout
d9cfc7df
779e7d56

 openssl x509 -in /etc/univention/ssl/ucsCA/certs/02.pem --issuer_hash --subject_hash -noout
d9cfc7df
779e7d56

as the pkg was reinstalled the ldapsearch looks good to me…

root@dcsc:~# ldapsearch -LLLZZx \
>   -H "$(sed -ne 's/^uri //p;T;q' /etc/pam_ldap.conf)" \
>   -D "$(sed -ne 's/^rootbinddn //p;T;q' /etc/pam_ldap.conf)" \
>   -y /etc/pam_ldap.secret \
>   -b "$(sed -ne 's/^base //p;T;q' /etc/pam_ldap.conf)" \
>   -s base
dn: dc=office,dc=firma,dc=com
dc: office
univentionObjectType: container/dc
krb5RealmName: OFFICE.FIRMA.COM
nisDomain: office.firma.com
associatedDomain: office.firma.com
univentionPolicyReference: cn=default-settings,cn=pwhistory,cn=users,cn=polici
 es,dc=office,dc=firma,dc=com
univentionPolicyReference: cn=default-users,cn=admin-settings,cn=users,cn=poli
 cies,dc=office,dc=firma,dc=com
univentionPolicyReference: cn=UCS 4.0,cn=desktop,cn=policies,dc=office,dc=firma,dc=com
objectClass: top
objectClass: krb5Realm
objectClass: univentionPolicyReference
objectClass: nisDomainObject
objectClass: domainRelatedObject
objectClass: domain
objectClass: univentionBase
objectClass: univentionObject
objectClass: msGPO
msGPOLink: [LDAP://cn={E3FCC602-B559-43F7-A805-485A72E6A7FD},cn=policies,cn=sy
 stem,DC=office,DC=firma,DC=com;0][LDAP://cn={EE351F7D-7A02-4592-B48F-FA69545
 5CC8C},cn=policies,cn=system,DC=office,DC=firma,DC=com;0][LDAP://CN={31B2F34
 0-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=office,DC=firma,DC=c
 om;0][LDAP://CN={256D85C6-D75E-4A40-85C0-2AC14D87D74A},CN=Policies,CN=System,
 DC=office,DC=firma,DC=com;0]

root@dcsc:~#

now it is completely screwed up…
if I do

univention-ldapsearch i get results
if i do univention-ldapsearch -base i get

root@dcsc:~# univention-ldapsearch -base
# extended LDIF
#
# LDAPv3
# base <ase> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 3
result: 34 Invalid DN syntax
text: invalid DN

# numResponses: 1

“ase” is not a valid base-dn for parameter “-b” :wink:
Maybe you meant univention-ldapsearch -s base

you are absolutely right ---- mea culpa—
I tried

univention-ldapsearch -base

which is of course wrong
using the command correctly shows

 univention-ldapsearch -H ldap://TM01-DC02.office.firma.com:7389 -s base
ldap_bind: Invalid credentials (49)

and on the PDC ist is working

root@dcsc:/etc/univention/ssl# univention-ldapsearch -H ldap://dcsc.office.firma.com:7389 -s base
# extended LDIF
#
# LDAPv3
# base <dc=office,dc=firma,dc=com> (default) with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

# office.firma.com
dn: dc=office,dc=firma,dc=com
dc: office
univentionObjectType: container/dc
krb5RealmName: OFFICE.FIRMA.COM
nisDomain: office.firma.com
associatedDomain: office.firma.com
univentionPolicyReference: cn=default-settings,cn=pwhistory,cn=users,cn=policies,dc=office,dc=firma,dc=com
univentionPolicyReference: cn=default-users,cn=admin-settings,cn=users,cn=policies,dc=office,dc=firma,dc=com
univentionPolicyReference: cn=UCS 4.0,cn=desktop,cn=policies,dc=office,dc=firma,dc=com
objectClass: top
objectClass: krb5Realm
objectClass: univentionPolicyReference
objectClass: nisDomainObject
objectClass: domainRelatedObject
objectClass: domain
objectClass: univentionBase
objectClass: univentionObject
objectClass: msGPO
msGPOLink: [LDAP://cn={E3FCC602-B559-43F7-A805-485A72E6A7FD},cn=policies,cn=system,DC=office,DC=firma,DC=com;0][LDAP://cn={EE351F7D-7A02-4592-B48F-FA695455CC8C},cn=policies,cn=system,DC=office,DC=firma,DC=com;0][LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=office,DC=firma,DC=com;0][LDAP://CN={256D85C6-D75E-4A40-85C0-2AC14D87D74A},CN=Policies,CN=System,DC=office,DC=firma,DC=com;0]

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

Good that it now works on dcsc. But still strange that some packages were not installed correctly or even removed. You might want to look at /var/log/apt/history.log and /var/log/apt/term.log for any hint on what went wrong.

So next look at tm01-dc02:

I guess they belong to the same domain

  • is one of them the Primary (domaincontroller_master)?
  • what system role does the other system have? Run ucr get server/role.

You should also run univention-check-join-status on tm01-dc02. I guess that system is not your Primary and something is wrong with the replication mechanism.