AD join failed

[Martin Kyrc]

We have WSA (S695, SW v14.0.4-005) with domain joining problems. Everything is configured correctly (DNS names, network connectivity, AD domain/servers/user with validity to joining computers to AD).

Situation:
- WSA not exists in AD as computer object. User add it to domain. Object created, WSA shows (direct after joining) that WSA is joined.
- BUT! after while (GUI refresh for example) WSA shows that is NOT joined in domain (Status: Computer account WSADEVICE$ not yet created)

Test under authentication page shows this error:

Attempting to get TGT...
Failure: Error while fetching Kerberos Tickets from server '10.101.33.40' :
kinit: Password incorrect

The same issue on different WSA (the same SW version). We can't solve this issue. we try to add it with different name, we try add it manually (on AD side),... but no success.

What else can we check for solving this issue?

martin

[balaji.bandi]

couple of things to check :

1. Make sure NTP time ok both side

2. what AD Server ?

3. make sure the user used admin rights in AD side ?

4. try to turn off WSA and Turn on test it.,

[Martin Kyrc]

Thanks @balaji.bandi , everything looks correct: time is correct (ntp) on both sides, admin rights with rights to add new devices to AD, AD (version 10.0.x) running on win server 2016. WSA was restarted - without help.

[amojarra]

Hi @Martin Kyrc 

As @Balaji mentioned please make sure you have correct admin rights, 

Also please confirm there is no duplicate name and/or you removed the WSA from AD completely,

Even though, the error message indicates a failure due to an incorrect password, this problem is actually caused by a configuration issue, where user has set the AD (Active Directory) Domain name on the NTLM Realm configuration using lower case letters and the actual Domain name on the AD server is configured with upper case letters.

Note: There's an help box (?) for the field: "Active Directory Domain" during the NTLM Realm configuration that says: The Active Directory Domain is also known as the DNS Domain or realm. This value is case-sensitive.

Use a Domain Admin account to join the domain that does not contain a $ in the password.

If above suggestions didn't help. please try to change the Auth_logs logging level to debug, to have more visibility on the issue.

Regards,

Amirhossein Mojarrad

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++        If you find this answer helpful, please rate it as such      ++++

+++++++++++++++++++++++++++++++++++++++++++++++++++

[Martin Kyrc]

@amojarra thanks for hints.

I'll check '$' character in admin password. 

Domain name is upper-case on AD side, also configured on WSA. The same AD is DNS server for clients (including WSA) in the network. Object 'my-wsa-03' is created as AD object type computer (upper-case name) but WSA tell is 'I'm not joined to AD domain'.

Ok, I'll try to change log level on WSA side. The right log is auth log?

[balaji.bandi]

Other addition to the comment, Make sure the user account you using to join domain, does not belong to various groups, may be i create a service account in AD with domain admin rights and use that ID for joining to AD.

[Martin Kyrc]

@balaji.bandi why is that important (User with admin rights without membership to other groups)? Customer uses admin user to add WSA to AD and WSA is successflu created (but from WSA point of view is not joined to domain). I will doublecheck it tomorrow with customer, but I'm interesting about it. Cam you clarify it for me?

Sorry for 'solution', it is not solved yet.

[balaji.bandi]

Not sure the reason, i have come across this issue, the admin from Server administrator try to join using his login, i have failed, so i dont remember the document (but later we create service account so we can register when ever we required) -it works as expected.

May be your case different, but just sharing the experience.

[amojarra]

Thanks @Martin Kyrc 

Yes the Auth_logs Please 

[Martin Kyrc · Accepted solution]

After several times add/remove "wsa" computer object is join successful.

Solution in our case:
- find and remove (computer) object "WSA" in AD
- doublecheck DNS records for "WSA" (including revers DNS records) in AD
- wait 10 minutes (for replication between AD servers)
- then the connection of WSA to AD is successful