Product Name/Version: AMP 2.3.2.0 (Triton), built 31/01/2022 18:02
Problem Description:
I tried to set up LDAP Authentication with my ActiveDirectory, it made a connection and recognized the user I tried to log in with but does not accept the login.
After some Troubleshooting, I started a Wireshark session to see what the server is trying to do and got the filter it uses to get the user object from LDAP to get the groups the user is part of.
The filter for this is set to: “(&(&(objectClass=person)(objectCategory=user))(sAMAccountname=[USER_IN_HEX]))”
the problem is in Windows Active Directory the objectClass and objectCategory is exactly the oposite (or atleast the ObjectCategory)
I am not to familiar with LDAP Querys it could also be that the whole sting from objectCategory is needed.
is there a way to make this compatible with ActiveDirectoy or am I missing something I would have to configure separately?
EDIT 10 minutes after posting:
I just tried some filters in LDAP this one seems to work:
it seems like ActiveDirectory does not support hex as samacountname searches.
which would bring a new problem:
at login, it is needed to use the msDS-PrincipalName or the username + @ + domain
which AMP does not seem to do but just sends the input of the username field as authentication.
Active Directory is what the current implementation has been validated for. What version of Windows Server are you using as the domain controller? And is it also configured as a nameserver to provide lookup information for the DC?
I run a windows server 2019, it is set up as a nameserver.
As mentioned the problem occurs after the (successful) login to LDAP with the provided user when the query tries to fetch the user object and the groups he is part of, if needed I can provide a capture from Wireshark with a dummy user as a test.
I can’t see why that’d happen, the code doesn’t alter the username you give it in any way:
using var de = new DirectoryEntry("LDAP://" + domain, username, password, AuthenticationTypes.Encryption);
using var directorySearcher = new DirectorySearcher(de);
directorySearcher.Filter = $"(&(objectClass=person)(objectCategory=user)(sAMAccountname={username}))";
directorySearcher.PropertiesToLoad.Add("sAMAccountname");
directorySearcher.PropertiesToLoad.Add("memberOf");
SearchResult searchResult = directorySearcher.FindOne();
I also can’t reproduce, I’m able to login to a 2016 and 2019 domain controller with the current release build or with the above code in a test bench.
also, the domain is not being sent or at least not visible in the trace
here is a screenshot of the authentication in Wireshark, the username and password are correct but no domain is being sent so it fails, IPs are correct.
somehow the hex value is also not right the \ad gets converted to just “:ad:” so some text is missing, but anyway the hex search with the right value does not work it just comes back with no matches.
i searched with the following sAMAccountname values (only the filter i was not able to authenticate without daw\ in front of the username):
admhountez in hex (61:64:6d:68:6f:75:6e:74:65:7a) - no results found
daw\admhountez in hex (64:61:77:5c:61:64:6d:68:6f:75:6e:74:65:7a) - no results found
hountez in plaintext - acount got found
daw\hountez in plaintext - no results found
it is also possible that Wireshark is not translating the hex values in the windows in the middle, but the translated value in the bottom window is also not complete.
