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
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/
ssh this is relevant as by default only members of group Administrators and Domain Admins are allowed.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 ?
/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.
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
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” 
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
domaincontroller_master)?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.
Hello pmhahn,
I’am getting
id: ‘Administrator’: no such user
so - as I understand - PAM cannot talk to LDAP.
How can I fix that or find out further details beloning to this problem?
My underlying problem is: No one is able anymore to log in to WebGUI. Only SSH is still possible to change configuration of the server.
I also tried some of the other test you mentioned:
ldapsearch -x -D "uid=Administrator,cn=users,$(ucr get ldap/base)" -w 'MY_ADMIN_PW' uid=Administrator 1.1
# extended LDIF
#
# LDAPv3
# base <dc=hitcons,dc=intranet> (default) with scope subtree
# filter: uid=Administrator
# requesting: 1.1
#
# Administrator, users, hitcons.intranet
dn: uid=Administrator,cn=users,dc=hitcons,dc=intranet
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
$ sudo systemctl status nscd.service
nscd.service - Name Service Cache Daemon
Loaded: loaded (/lib/systemd/system/nscd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-11-02 14:49:29 CET; 1 day 4h ago
Process: 812 ExecStart=/usr/sbin/nscd (code=exited, status=0/SUCCESS)
Main PID: 816 (nscd)
Tasks: 21 (limit: 4915)
Memory: 21.7M
CGroup: /system.slice/nscd.service
└─816 /usr/sbin/nscd
Nov 03 19:00:02 ucs-1755 nscd[816]: nss_ldap: failed to bind to LDAP server ldap://ucs-1755.hitcons.intranet:7389: Invalid credentials
Nov 03 19:00:02 ucs-1755 nscd[816]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Nov 03 19:00:03 ucs-1755 nscd[816]: nss_ldap: failed to bind to LDAP server ldap://ucs-1755.hitcons.intranet:7389: Invalid credentials
Nov 03 19:00:03 ucs-1755 nscd[816]: nss_ldap: could not search LDAP server - Server is unavailable
Nov 03 19:09:05 ucs-1755 nscd[816]: nss_ldap: failed to bind to LDAP server ldap://ucs-1755.hitcons.intranet:7389: Invalid credentials
Nov 03 19:09:05 ucs-1755 nscd[816]: nss_ldap: reconnecting to LDAP server...
Nov 03 19:09:05 ucs-1755 nscd[816]: nss_ldap: failed to bind to LDAP server ldap://ucs-1755.hitcons.intranet:7389: Invalid credentials
Nov 03 19:09:05 ucs-1755 nscd[816]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Nov 03 19:09:06 ucs-1755 nscd[816]: nss_ldap: failed to bind to LDAP server ldap://ucs-1755.hitcons.intranet:7389: Invalid credentials
Nov 03 19:09:06 ucs-1755 nscd[816]: nss_ldap: could not search LDAP server - Server is unavailable
Sorry, I am newbie concerning PAM an LDAP communication! So can you help me out?
Ahh, by the way: running UCS 5.0
Thanxx
Please always repport the UCS version you’re using and the server role, e.g. ucr search --brief ^version/ ^server/role
nscd failed to connect to your LDAP server.
Is ucs-1755.hitcons.intranet:7389 your UCS Primary (DC Master)?
Can that name be resolved via getent hosts ucs-1755.hitcons.intranet?
Can you ping the host? ping -c 5 ucs-1755.hitcons.intranet?
Check /etc/libnss-ldap.conf:
messagebug:root and have permissions 0440, e.g. only readable for user and group.uri ldap://... match the name of your Primary/Master?rootbindn cn=.. and binddn cn=… match the output of ucr get ldap/hostdn?bindpw … march the content of /etc/machine.secret?ucr commit /etc/libnss-ldap.conf to re-create that file. Afterwards do a systemctl restart nscd.service.ldapsearch -xLLLo ldif-wrap=no -H ldap://ucs-1755.hitcons.intranet:7389 -D "$(ucr get ldap/hostdn)" -y /etc/machine.secret -b "$(ucr get ldap/hostdn)" -s base
/etc/machine.secret may no longer match what is stored in LDAP on the Primary/Master. If you know it you can write it with echo -n 'SECRET' >/etc/machine.secret to that file; otherwise
/etc/machine.secret; referenced as $PASS further onucr get ldap/hostdn → $DN
ucr get server/role → $ROLE
root and run udm "computes/$ROLE" modify --dn "$DN" --set password="$PASS" to set the password in LDAP to the same value currently in /etc/machine.secret on the affected system.Afterwards check that the above ldapsearch … then works.