UMC logon not possible after IP change

UCS - Univention Corporate Server
, , ,
#1

Hello,

I have strange problem with an UCS 4.3 connected to an MS AD.
If I change the IP of this UCS, I cannot login to the UMC anymore. After I enter the login credentials, the site reloads to the page where I can enter my login credentials, It’s an endless loop.

When I switch back to the old IP via the console, everything works fine, again.
I tried solving the problem with forcing to execute all joining scripts, but this didn’t help

The univention-console-web-server.log shows these entries:

29.04.18 14:54:57.628  MAIN        ( PROCESS ) : SessionClient(0x7efc38799190): _authenticated: success=True  status=200  message=None
29.04.18 14:54:57.628  MAIN        ( PROCESS ) : auth_type=None
29.04.18 14:55:16.117  MAIN        ( PROCESS ) : SessionClient(0x7efc38799ad0): _authenticated: success=True  status=200  message=None
29.04.18 14:55:16.118  MAIN        ( PROCESS ) : auth_type=None
29.04.18 14:56:12.976  MAIN        ( PROCESS ) : SessionClient(0x7efc3872c250): _authenticated: success=True  status=200  message=None
29.04.18 14:56:12.977  MAIN        ( PROCESS ) : auth_type=None
29.04.18 14:59:36.858  MAIN        ( PROCESS ) : SessionClient(0x7efc3873c290): _authenticated: success=True  status=200  message=None
29.04.18 14:59:36.858  MAIN        ( PROCESS ) : auth_type=None
29.04.18 15:07:26.479  MAIN        ( PROCESS ) : SessionClient(0x7efc3873cf90): _authenticated: success=True  status=200  message=None
29.04.18 15:07:26.480  MAIN        ( PROCESS ) : auth_type=None

The univention-console-server.log shows these entries:

29.04.18 14:54:57.470  MODULE      ( PROCESS ) : Setting auth type to None
29.04.18 14:54:57.627  MAIN        ( PROCESS ) : Updating user password in 0 running module processes (auth-type: None).
29.04.18 14:55:16.001  MODULE      ( PROCESS ) : Setting auth type to None
29.04.18 14:55:16.018  ACL         ( WARN    ) : Error reading credentials from LDAP: Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/management/console/acl.py", line 368, in _read_from_ldap
    userdn = self.lo.searchDn(filter_format('(&(objectClass=person)(uid=%s))', [self.username]), unique=True)[0]
IndexError: list index out of range

29.04.18 14:55:16.116  MAIN        ( PROCESS ) : Updating user password in 0 running module processes (auth-type: None).
29.04.18 14:55:16.222  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:20.283  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:27.364  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:27.364  MAIN        ( PROCESS ) : Processor: dying
29.04.18 14:55:27.364  MAIN        ( PROCESS ) : Processor: dying
29.04.18 14:55:27.782  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:28.225  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:31.683  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:45.889  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:45.889  MAIN        ( PROCESS ) : Processor: dying
29.04.18 14:55:45.889  MAIN        ( PROCESS ) : Processor: dying
29.04.18 14:55:46.371  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:47.086  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:55:51.172  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:56:12.791  MODULE      ( PROCESS ) : Setting auth type to None
29.04.18 14:56:12.975  MAIN        ( PROCESS ) : Updating user password in 0 running module processes (auth-type: None).
29.04.18 14:56:42.677  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:56:42.677  MAIN        ( PROCESS ) : Processor: dying
29.04.18 14:56:42.677  MAIN        ( PROCESS ) : Processor: dying
29.04.18 14:56:43.133  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:56:43.808  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:56:47.488  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 14:59:36.726  MODULE      ( PROCESS ) : Setting auth type to None
29.04.18 14:59:36.856  MAIN        ( PROCESS ) : Updating user password in 0 running module processes (auth-type: None).
29.04.18 15:00:01.616  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:00:06.608  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:00:06.608  MAIN        ( PROCESS ) : Processor: dying
29.04.18 15:00:06.608  MAIN        ( PROCESS ) : Processor: dying
29.04.18 15:00:07.001  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:00:07.910  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:00:11.324  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:07:26.219  AUTH        ( WARN    ) : Canonicalization of username was not possible: Invalid credentials
29.04.18 15:07:26.309  MODULE      ( PROCESS ) : Setting auth type to None
29.04.18 15:07:26.478  MAIN        ( PROCESS ) : Updating user password in 0 running module processes (auth-type: None).
29.04.18 15:07:56.197  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:07:56.197  MAIN        ( PROCESS ) : Processor: dying
29.04.18 15:07:56.197  MAIN        ( PROCESS ) : Processor: dying
29.04.18 15:07:56.735  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:07:57.411  MAIN        ( PROCESS ) : Connection timed out.
29.04.18 15:08:00.874  MAIN        ( PROCESS ) : Connection timed out.

Querying the LDAP via console was fine.

I’m a little bit confused, because this is the first time, I saw an UCS with this problem after changing the IP, but I must say, this was the first 4.3 UCS with IP change, also.

Thanks in advanced for every hint on solving this problem.

Christian.

#2

Hey,

to me this sounds like a DNS issue, e.g. something like the following:

  1. You change the server’s IP address.
  2. During login, the UMC attempts an LDAP search for the user logging in. It uses the server’s host name.
  3. That LDAP search fails as the host name still resolves to the old address.

Now you said that this is an “AD-connected system”. Does that mean that your Windows AD server is the your domain’s primary DNS?

Maybe something along these lines will work:

  1. change the UCS server’s IP,
  2. change the corresponding DNS entries in your AD,
  3. reboot your UCS server (which is a sure but somewhat heavy-handed way of flushing all kinds of DNS caches on the machine)

Kind regards,
mosu

#3

Hi Moritz,

I changed the DNS entries on the Windows AD Server and rebootet the UCS several times, but without any success.
Now, we decided to leave it on the old IP address because the kerberos cache was messed up also and we had too many issues with this system.
After cleaning up all the mess and leaving the ip address unchanged, everything works well. :slight_smile:

But tyvm for your ideas!
Christian.

Mastodon