Problems accessing Windows resources
My account has been blocked and I can no longer log in. What can I do?
The user account is automatically blocked if an incorrect password is entered three times. However, the account is automatically unblocked again after 5 minutes. If you don't want to wait, you can also contact your department admin or the computer support team, who can unblock the account immediately.
I cannot access my profile and my home directory when I log on to a Windows computer.
If logging on to a Windows computer works, but the home directories or user profiles cannot be accessed afterwards, there may be several reasons for this:
- The computer cannot access the SAMBA server for some reason.
- The account is automatically locked when logging on to the computer.
In both cases, the problem can only be resolved by a specialist group admin or the computer support team.
Why is my account always locked when I log on to a computer?
There are several reasons for this:
- A network connection is saved in the profile, which attempts to re-establish it with an incorrect password when logging in. As a result, this incorrect password is sent to the Windows server, which then locks the account.
- There is still an old connection to a network directory somewhere on another computer. If this connection is older than seven days, the Kerberos tickets used have expired and the account is also automatically locked as soon as the network connection is somehow activated. This is often the case with long-running processes that attempt to write result or log files to network drives. Programmes that are active for longer than seven days should therefore be avoided.
- The computer was not shut down or restarted properly. Apparently, the MIT Kerberos client cannot empty its Kerberos ticket cache, so that it uses old tickets for the login, which leads to the user account being blocked. The only solution here is to reinstall the MIT Kerberos client.
In general, you should always log out when you finish work and go home. Then no problems should actually occur.
I have a notebook that is not integrated into the Windows domain and cannot access any network directories.
If a notebook is in the Windows domain HNI.UNI-PADERBORN.DE, you can access all HNI resources without any problems. External notebooks, however, lack the corresponding configurations, so that the authorisation for access to the resources does not work. Even if the corresponding settings have been added manually, an error in Microsoft's implementation prevents the authorisation from working properly. Unfortunately, Microsoft itself has not yet been able to offer a solution to this problem.
Under Linux, you can access all resources without any problems after configuring the clients accordingly.
I always hear Kerberos, what is that anyway?
Kerberos is a protocol for authentication and authorisation. In contrast to the usual procedures, where the password must always be sent to the servers via the network, the authentication mechanism works locally on the computer on which the user wants to log in or from which he requests resources.
For this purpose, so-called tickets are used, which are issued by a central server, the Kerberos server, and sent to the requesting client in encrypted form. These tickets are then decrypted on the local computer.
Kerberos can also be used to enable single sign-on, provided the applications used support this. As the tickets can be used universally and services can also use tickets, it is possible for the user's ticket to be used for authorisation to the service and vice versa. Communication can also be encrypted.
More information on this topic can be found at web.mit.edu/kerberos/.
But Kerberos causes major problems, why do we use it at all?
It is not Kerberos that causes the problems, but the applications that do not support Kerberos properly.
Windows, for example, recognises two equally valid authentication protocols: NTLM (NT Lan Manager) and Kerberos. A distinction must be made between two versions of NTLM: Version 1, which sends the passwords in plain text, and NTLMv2, which uses a hash value of the passwords.
According to Microsoft, however, the preferred protocol is Kerberos. However, we found that this only applies in some areas, so that Windows always falls back on NTLM (and not always NTLMv2) where Kerberos does not work.
I have an application that does not support Kerberos properly. What can I do?
In this case, a local password must be set in the HNI.UNI-PADERBORN.DE domain. This ensures that Windows and all services can use NTLM again if necessary.
Where can I set a local password?
On the computer called hni-pwm. There is a menu item for the HNIRB domain under Start/Programs/Change HNI Password Manager, which can be used to reset the password in the domain.
Do I have any disadvantages if I reset my password?
Windows uses the user's password in various places (e.g. when using the Encrypted File System EFS to encrypt the partitions). As the password is only reset and not changed, the change is not made at these points. Partitions protected with EFS can then no longer be used and the data is lost.