Teamcity 2022.10.1 NTLM Login with Windows 11 fails for samAccountName with diacritic marks Follow
Hello,
i need some help for a most basic Teamcity setup.
I installed Teamcity 2022.10.1 with default database and a own service account domain\teamcity.
Installation was done on Windows 2022 Server in a Windows Domain.
I switched to Windows Domain Login with an LDAP Config and NTLM HTTP as allowed protocol.
All Clients with Windows 10 have no Problem with a login, only Windows 11 Clients fail to login.
But they only fail, if the user has some diacritics marks (Umlauts or ä ö ü) in his name (samAccountName)!
Other have no problems with a login under Windows 11
I assumes that this has todo with security and the switch to kerberos authentication in Windows 11.
What settings am i missing for kerberos login
Thanks in advance
Jürgen
This is my LDAP config
java.naming.referral=follow
java.naming.provider.url=ldap://srv-dc-01.domain.name.de:389/DC=domain,DC=name,DC=de
java.naming.security.authentication=simple
# LDAP credentials for TeamCity plugin.
java.naming.security.principal=TeamCityLDAPRead
java.naming.security.credentials=SimplePassword
# Synchronize both users and groups. Remove obsolete TeamCity users, but don't create new ones automatically.
teamcity.options.users.synchronize=true
teamcity.options.groups.synchronize=true
teamcity.options.createUsers=false
teamcity.options.deleteUsers=true
teamcity.options.syncTimeout=3600000
# Search users from the root: 'DC=example,DC=com'.
teamcity.users.base=
teamcity.users.filter=(objectClass=user)
teamcity.users.username=sAMAccountName
teamcity.users.property.displayName=name
teamcity.users.property.email=mail
# Search groups from 'CN=groups,DC=example,DC=com'.
teamcity.groups.base=OU=Member,DC=domain,DC=name,DC=de
teamcity.groups.filter=(objectClass=group)
teamcity.groups.property.member=member
Please sign in to leave a comment.
Hello Juergen,
May I ask you to enable debug-ldap logging preset, have any of the users with problematic username try to log in and share the resulting teamcity-auth.log, teamcity-ldap.log files?
Hi
the ldap log has no new information since
[2023-01-24 09:07:33,415]
The user login Jürgen startet around 09:17
teamcity-auth.log
i tried to change NTML HTTP to Negotiate, NTLM, Kerberos ...
but i never had any LDAP Log entries.
I added the server url to the trusted zone
I added wildcard certificate and enabled SSL
On some Linux/Ubuntu System with tomcat and Znuny i need to set some coding in LDAP Config to UTF-8.
I even needed to change some code of Znuny to handle UTF-8 correctly.
Linux gets a samAccountName with some diacritic Marks in a Base64 encoded hex string...
Is there any documentation to enable kerberos/negotiate ?
do i need a SPN for the Host or HTTP?
I tried both, one for the Host (per default present) and i set a SPN for http domain\teamcity service account
didn´t change anything
Where can i get support for this problem?
Hello Juergen,
Thank you for the data provided and apologies for the delayed response here. As per the below stack trace excerpt:
Remote server refuses the logon attempt, but unfortunately the exception message does not provide any extra details. Do you see any relevant logs in the Event Viewer for the server handling authentication that could bring some light on why exactly the logon attempt was refused?
Hello Fedor,
i tried different setup now.
This looks realy weired and somehow familiar with Tomcat/Linux and Znuny/Otrs problems i solved recently.
I have a clean Windows 11 Pro Machine, with no user logged on after setup.
If a user (me) with a diacritic mark in samAccountName (Jürgen) logs on the first time and opens the Teamcity Server all is fine and the user (me) can logon. i can do this several times (logout of Windows, logon and open Teamcity Server).
And after a couple of minutes 5-15 it fails with these problems.
I get a Windows Authentication box asking for username and password.
If i enter my pre-Windows 2000 account (domain\Jürgen) i cant logon.
If i enter my email adress i can enter Teamcity without any problems.
Now i changed the ldap-config.properties to
# Active Directory:
#teamcity.users.username=sAMAccountName
teamcity.users.username=mail
The logon is now possible from all Windows 11 machines, that failed previously.
Back to tomcat/znuny/otrs ...
In a linux system i need to tell tomcat, that the logon credential will be UTF-8 formated.
In the LDAP settings from znuny/otrs i need to tell the LDAP properties to tread the SamAccountName as UTF-8 and check for binary string.
Active Directory will send the SamAccountName base64 encoded if there is any UTF-8 doublebyte character inside (diacritic marks, ä ö ü).
And if that is not all, i needed to modify the znuny/otrs scripts to read the username as UTF-8 coded.
And with all these settings, it works finally with tomcat/znuny/ldap/...
I think that Teamcity needs some additional code to trade the SamAccountName name as UTF-8 or base64 decoded.
With the change to use the email, i think i can live with that.
Can you verify my findings?
Jürgen
Hi,
i need to report back, that even with teamcity.users.username=mail it´s failing now!
Teamcity seems to be finicky...
Thank you for the update! I have reached out to the development team to discuss the issue further and will circle back to you shortly.
Hi,
i did some more testing today and i was able to login from a different Subnet. But i don´t think this makes any difference.
I upated the new build TeamCity Professional 2022.10.2 (build 117025) today.
Release notes are talking about 6 new security fixes, but no information written.
These are two logs parts, the first is not working, the second does.
same user, but only different machines.
Windows 2019 Server 192.168.0.128
Windows 11 Client 192.168.10.96
16:33:19,962] - Processing request with no authorization header: GET '/', from client 192.168.0.128:63900, no auth
16:33:19,962] - [Presigned-Token Authentication] Authentication scheme is not enabled. jetbrains.buildServer.controllers.filters.DisableSessionCookieTokenAuthFilter$WrappedRequest@2febca96
16:33:19,962] - Request from origin https://tc-server is allowed by HTTP-Authentication scheme disabling logins from forbidden domain
16:33:19,962] - No scheme was matched
16:33:19,962] - Creating session 5EE393A931... (created: 2023-02-06 16:33:19.962, timeout: 3600s)
16:33:19,962] - Processing unauthenticated request
16:33:19,962] - Redirecting to login page
16:33:20,072] - Generated CSRF token 2764e460-d9e2-4e74-953f-5de1ce281ac8 for session 5EE393A9311054EBDCC6E1E0FD4E0B08
16:33:24,288] - Processing request with no authorization header: GET '/ntlmLogin.html', from client 192.168.0.128:63905, no auth
16:33:24,288] - [Presigned-Token Authentication] Authentication scheme is not enabled. jetbrains.buildServer.controllers.filters.DisableSessionCookieTokenAuthFilter$WrappedRequest@7108d781
16:33:24,288] - Request from origin https://tc-server is allowed by HTTP-Authentication scheme disabling logins from forbidden domain
16:33:24,288] - Matched authentication scheme: jetbrains.buildServer.controllers.interceptors.auth.impl.NTLMHttpAuthenticationSchemeImpl, authResult: UNAUTHENTICATED
16:33:24,288] - Responding with 401 HTTP status with message "Unauthorized: No Authorization header specified. The browser might not support any of the authentication schemes available or authentication cancelled.", sending header in response: WWW-Authenticate: NTLM
16:33:27,789] - Processing request with no authorization header: GET '/ntlmLogin.html', from client 192.168.0.128:63900, no auth
16:33:27,789] - [Presigned-Token Authentication] Authentication scheme is not enabled. jetbrains.buildServer.controllers.filters.DisableSessionCookieTokenAuthFilter$WrappedRequest@6b75e723
16:33:27,789] - Request from origin https://tc-server is allowed by HTTP-Authentication scheme disabling logins from forbidden domain
16:33:27,789] - Matched authentication scheme: jetbrains.buildServer.controllers.interceptors.auth.impl.NTLMHttpAuthenticationSchemeImpl, authResult: UNAUTHENTICATED
16:33:27,789] - Responding with 401 HTTP status with message "Unauthorized: No Authorization header specified. The browser might not support any of the authentication schemes available or authentication cancelled.", sending header in response: WWW-Authenticate: NTLM
16:29:20,636] - Processing request with no authorization header: GET '/', from client 192.168.10.96:56255, no auth
16:29:20,636] - [Presigned-Token Authentication] Authentication scheme is not enabled. jetbrains.buildServer.controllers.filters.DisableSessionCookieTokenAuthFilter$WrappedRequest@39336504
16:29:20,636] - Request from origin https://tc-server is allowed by HTTP-Authentication scheme disabling logins from forbidden domain
16:29:20,636] - No scheme was matched
16:29:20,652] - Creating session 161E87C618... (created: 2023-02-06 16:29:20.636, timeout: 3600s)
16:29:20,652] - Processing unauthenticated request
16:29:20,652] - Redirecting to login page
16:29:20,652] - Generated CSRF token 344317ae-06e2-46b3-b2a0-1ee3fdb64c21 for session 161E87C618865D34C4E77BE54E312519
16:29:22,431] - Processing request with no authorization header: GET '/ntlmLogin.html', from client 192.168.10.96:56255, no auth
16:29:22,431] - [Presigned-Token Authentication] Authentication scheme is not enabled. jetbrains.buildServer.controllers.filters.DisableSessionCookieTokenAuthFilter$WrappedRequest@561e43f4
16:29:22,431] - Request from origin https://tc-server is allowed by HTTP-Authentication scheme disabling logins from forbidden domain
16:29:22,431] - Matched authentication scheme: jetbrains.buildServer.controllers.interceptors.auth.impl.NTLMHttpAuthenticationSchemeImpl, authResult: UNAUTHENTICATED
16:29:22,431] - Responding with 401 HTTP status with message "Unauthorized: No Authorization header specified. The browser might not support any of the authentication schemes available or authentication cancelled.", sending header in response: WWW-Authenticate: NTLM
16:29:22,441] - Processing request with authorization header protocol: 'NTLM': GET '/ntlmLogin.html', from client 192.168.10.96:56255, no auth
16:29:22,441] - [Presigned-Token Authentication] Authentication scheme is not enabled. jetbrains.buildServer.controllers.filters.DisableSessionCookieTokenAuthFilter$WrappedRequest@26956f05
16:29:22,441] - Request from origin https://tc-server is allowed by HTTP-Authentication scheme disabling logins from forbidden domain
16:29:22,441] - Using connectionId generator "sessionAndRequestUrl"
16:29:22,441] - Using processor "caching"
16:29:22,441] - Creating new handlers cache for key 161E87C618..._1345674790
16:29:22,441] - Resetting Waffle connection for id 161E87C618..._1345674790
16:29:22,441] - Will continue authentication for request connectionId: 161E87C618..._1345674790, messageType: 1, authHeader: "NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAKAGFKAAAADw=="
16:29:22,441] - Using auth handler: Continue with WWW-Authenticate header
16:29:22,441] - Matched authentication scheme: jetbrains.buildServer.controllers.interceptors.auth.impl.NTLMHttpAuthenticationSchemeImpl, authResult: UNAUTHENTICATED
16:29:22,456] - Responding with 401 HTTP status with message "Unauthorized", sending header in response: WWW-Authenticate: NTLM TlRMTVNTUAACAAAABgAGADgAAAAFgomi3MJfSmZHO6AAAAAAAAAAAKgAqAA+AAAACgB8TwAAAA9NAEIASQACAAYATQBCAEkAAQAaAFMAUgBWAC0AVABDAC0AUwBFAFIAVgAwADIABAAYAGcAaABhAG4AYQAuAG0AYgBpAC4AZABlAAMANABzAHIAdgAtAHQAYwAtAHMAZQByAHYAMAAyAC4AZwBoAGEAbgBhAC4AbQBiAGkALgBkAGUABQAYAGcAaABhAG4AYQAuAG0AYgBpAC4AZABlAAcACAAPQqPJPzrZAQAAAAA=
16:29:22,784] - Processing request with authorization header protocol: 'NTLM': GET '/ntlmLogin.html', from client 192.168.10.96:56255, no auth
16:29:22,800] - [Presigned-Token Authentication] Authentication scheme is not enabled. jetbrains.buildServer.controllers.filters.DisableSessionCookieTokenAuthFilter$WrappedRequest@6c9cd3b8
16:29:22,800] - Request from origin https://tc-server is allowed by HTTP-Authentication scheme disabling logins from forbidden domain
16:29:22,800] - Using connectionId generator "sessionAndRequestUrl"
16:29:22,800] - Using processor "caching"
16:29:22,800] - Found handlers cache for key 161E87C618..._1345674790
16:29:22,862] - Authentication sequence successful: principal name = "null", security package = "NTLM", continue = false, fqn = "domain\Jürgen"
16:29:22,862] - Using auth handler: Successful login: "domain\Jürgen"
16:29:22,862] - Matched authentication scheme: jetbrains.buildServer.controllers.interceptors.auth.impl.NTLMHttpAuthenticationSchemeImpl, authResult: AUTHENTICATED:jürgen
16:29:22,862] - Destroying session 161E87C618... (created: 2023-02-06 16:29:20.636, timeout: 3600s, last accessed: 2023-02-06 16:29:22.612)
16:29:22,862] - Creating session FC4953841F... (created: 2023-02-06 16:29:22.862, timeout: 3600s)
16:29:22,862] - Successful login for user 'jürgen' {id=41} with auth module "HTTP-NTLM" for session FC4953841F... (new, created: 2023-02-06 16:29:22.862, timeout: 3600s) while processing request GET '/ntlmLogin.html', from client 192.168.10.96:56255, authenticated as 'jürgen' {id=41}
16:29:28,216] - Expired tokens removed []
16:29:38,225] - Expired tokens removed []
Hi, i think i solved this mystery.
I enabled all Proctolls "NTLM, Negotiate, Kerberos" and i set a Service Principal Name (SPN) for the Service Account i used in the setup.
So this seems to work now, even for users with Diacritic Marks. Like Jürgen or Müller ...