ALL Users no longer can login

UCS - Univention Corporate Server
1

HELP!

Right now none of my windows users can log into my UCS Domain, not even Administrator. Logging into the UCS Management Console still works for Administrator.

Users either get that their account is disabled “Your Account has been disabled. Please see your System Administrator.” (but it not disabled in UCS Management Console GUI under users module) or in the case of the Administrator Account, get the error:
“Logon failure: user account restriction. Possible reasons are blank passwords not allowed, logon hour restrictions, or a policy restriction has been enforced.”, Now ever passwords are not blanks, there are not hours restrictions and there should be no policies…

I have tried restarting SAMBA4. This all started after updating to release version is 4.0-1 errata95.

Nothing in the logs stands out. I’ve tried everything in this article in the Support Database. sdb.univention.de/content/6/243/ … ogons.html

Still no one can log in. Rebooted the Master, Backup and Slave UCS DC. Still can’t log in.

Now I am at a loss.

2

This issue has degraded, going to see if support will help, But now I am not able to log into the UCS Management Console as Administrator either, can’t change passwords on any user either.

3

Hi.

this really sounds difficult as I cannot see any plausible reason for this situation.
You do have a DC Master, a DC Backup and a DC Slave, right?
I suppose Samba 4 is installed at each system, is this correct?
From what I understand till now both erros you report while loging in at windows clients are happening with problems at local users (not domain users). In case of administrator: If only specifying “administrator” as user, a windows client will try to use this as the local user (which often is disabled on windows clients per default) - if you want to login with the domain account “administrator”, you have to use domainname\administrator as user (please adapt “domainname”).

When it comes to UMC: What kind of error message do you get when logging in as administrator at your master? Is a login possible at the UMC on the DC Backup?

Are you able to login your DC Master using SSH or directly at the console?
If this works please try to do the following (and send us the output):

smbclient -L localhost -U Administrator kinit administrator klist

Please also try to work on “How to determine the status of the system?”

Kind regards,
Tim Petersen

4

Yes we have all three, only Samba 4 is installed on the Master and Backup, but not on the slave.

We have tried DOMAIN\USER and it also fails.

The UMC error, is “you password is expired please change it.” Then prompts for old password, and new password, retype new password. Then get this account is disabled.

I can only SSH into the MASTER:

For the following commands:
smbclient -L localhost -U Administrator
I get :
Enter Administrator’s password:
session setup failed: NT_STATUS_LOGON_FAILURE

For kinit administrator
I get:
administrator@DATACENTER.BEBCONSULTINGSERVICES.COM’s Password:
kinit: krb5_get_init_creds: Password has expired

For klist
I get:

root@ucs-1274:~# klist
klist: No ticket file: /tmp/krb5cc_0

However we do not have passwords that expire, we have not implemented this policy yet.

root@ucs-1274:~# univention-check-join-status
Joined successfully

root@ucs-1274:~# ucr search version/version version/patchlevel version/errata
Four types of UCS updates are differentiated: Major releases (released approxim ately every four years, may introduce bigger changes), minor releases (released approximately every 6-8 months, error corrections and new functions), patch leve l releases (released every 2-3 months, less changes compared to a minor release, focus on bugfixes) and errata updates (timely bugfixes for security problems an d critical bugs). This variable is set automatically during updates and contains the version of the installed errata updates.

version/patchlevel: 1
Four types of Univention Configuration Registry updates are differentiated: Maj or releases (released approximately every four years, may introduce bigger chang es), minor releases (released approximately every 6-8 months, error corrections and new functions), patch level releases (released every 2-3 months, less change s compared to a minor release, focus on bugfixes) and errata updates (timely bug fixes for security problems and critical bugs). This variable is set automatical ly during updates and contains the version of the installed patch level release.

version/version: 4.0
Four types of UCS updates are differentiated: Major releases (released approxim ately every four years, may introduce bigger changes), minor releases (released approximately every 6-8 months, error corrections and new functions), patch leve l releases (released every 2-3 months, less changes compared to a minor release, focus on bugfixes) and errata updates (timely bugfixes for security problems an d critical bugs). This variable is set automatically during updates and contains the version of major and minor update.

root@ucs-1274:~# dpkg --audit
root@ucs-1274:~#

root@ucs-1274:~# smbclient -UAdministrator //$(ucr get hostname)/sysvol -c quit
Enter Administrator’s password:
session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE

root@ucs-1274:~# univention-ldapsearch -s base -LLL dn
dn: dc=datacenter,dc=bebconsultingservices,dc=com

root@ucs-1274:~# grep “oom|segfault” /var/log/syslog
root@ucs-1274:~#

By all indications I need to change the Administrator password, However I need to be able to log in to change it. Also all our users seem to need to change their passwords too. We never set this as a policy yet.

5

[quote=“BrianBonnell”]
By all indications I need to change the Administrator password, However I need to be able to log in to change it. Also all our users seem to need to change their passwords too. We never set this as a policy yet.[/quote]

You can try to fully reset the administrator account as root at shell (simply adjust the “password=” value to the password you want to use):

udm users/user modify \ --dn uid=Administrator,cn=users,$(ucr get ldap/base) \ --set password=univention \ --set overridePWHistory=1 \ --set overridePWLength=1 \ --set primaryGroup="cn=Domain Admins,cn=groups,$(ucr get ldap/base)" \ --policy-reference="cn=default-admins,cn=admin-settings,cn=users,cn=policies,$(ucr get ldap/base)"

Afterwards you should be able to login again in UMC as administrator and you safely can restore the other users there.

6

Hello,
this also happened on our internal installation (only UCS DC Master, no other DC) after upgrade 4.0-1 for some “services-users” which we use for starting services or autologon for jobservers. Those users logged in during the update where locked out with the same “Account disabled” error message. Re-enabling the accounts with “AD Users and Computers” did NOT work, I had to disable and re-enable them trough UMC. After this step, the problem went away.
But I thought the culprit was the Microsoft-SBS imported policy which should temporarily disable user accounts after a certain amount of failed logins (which did not work with UCS 3.x - the users never where re-enabled - known bug).

Best regards,
TP

7

[quote=“The Preacher”],
this also happened on our internal installation (only UCS DC Master, no other DC) after upgrade 4.0-1 for some “services-users” which we use for starting services or autologon for jobservers. Those users logged in during the update where locked out with the same “Account disabled” error message.
But I thought the culprit was the Microsoft-SBS imported policy which should temporarily disable user accounts after a certain amount of failed logins (which did not work with UCS 3.x - the users never where re-enabled - known bug).
[/quote]

Thanks for the clarification! But I don’t think that these are the same things. “Your” scenario is discussed at Samba ADDC: badPwdCount not reset directly after unlock.

So all users which did a logon while updating from UCS 4.0-0 to UCS 4.0-1 were locked out? Is this correct?

Kind regards,
Tim Petersen

8

[quote=“Petersen”]

Thanks for the clarification! But I don’t think that these are the same things. “Your” scenario is discussed at Samba ADDC: badPwdCount not reset directly after unlock.

So all users which did a logon while updating from UCS 4.0-0 to UCS 4.0-1 were locked out? Is this correct?

Kind regards,
Tim Petersen[/quote]

Yes, that’s correct - the users which were already logged in were locked out after the update.

9

This is a bigger problem than I initially thought. I will continue here: http://forum.univention.de/viewforum.php?f=48