18.0.4 MR-4: AD join issues!!

Hi ,

Thank you for reaching out to the Community! 

Did you configure the AD admin user? 

Was there any recent update on your server? For testing, can you try to change the port to 389 and check your server's internal certificate? Is it valid? 

Did you put the access_server service in debug before collecting these logs?

Can you provide packet capture from your server and the firewall? 

Thanks,

I've seen similar behaviour last week (when just setting up XG and no real former experience). What I have noticed is that while AD is configured for SSL on port 636, AD SSO still tries port 389 unencrypted. Our domain doesn't accept that.

Solution from Lucar Toni was to deselect AD SSO from all zones. See this topic.

Unknown said:

Did you configure the AD admin user? 

Was there any recent update on your server? For testing, can you try to change the port to 389 and check your server's internal certificate? Is it valid? 

Did you put the access_server service in debug before collecting these logs?

Can you provide packet capture from your server and the firewall? 

Hi 

1) Yes

2) No - tried changing ports already

3) yes

4) Packet trace shows that XG connect with port 389 even though I have set for 636 above - not good :-(

Thanks for posting this, I have the same bug (Bug ID for this: NC-66450)

But I cannot disable AD SSO as Sync. user Id with heartbeat will stop working...

It seems to be the case, that your account, which you select for XG, does not have the rights to create a AD computer. 

Jan 06 20:32:08.315408 [nasm] NT_STATUS_ACCESS_DENIED: {Access Denied} A process has requested access to an object but has not been granted those access rights. (0xc0000022)

This indicates this assumption. 

Check the AD server log, if you see any LDAP errors. https://ldapwiki.com/wiki/LDAP%20Result%20Codes

That is actually not correct - Its not your bug ID. If you do not want to use NTLM/Kerberos, you can disable AD SSO in the Zone. Sync-Sec User ID will use Client Authentication for authentation, not AD SSO. 

But I need it also for authenticating SSLVPN users.

The AD Computer object is created successfully every time, if I delete it, it's being recreated  as wanted.

I use domain admin for the account. Issue is that XG connects on port 389 and not 636 as I need.

AD SSO is only NTLM/Kerberos. This has nothing to do with any other authentication services. AD SSO is basically the web based authentication in UTM (Also called AD SSO there), which you only use for Web Proxy. 

Thats the current bug ID, that is correct, port if you open Port 389, will it work or not? If not, you need to dump the Port389 traffic and export this tcpdump into wireshark. Then check, what is actually denying the join.