Hello,

after upgrading to 9.9.10, the AD login is not working anymore.

The server_log says



However, this issue seems to be related to remote clients only. Local clients can still login via AD users. Remote login is still possible for non-AD users.

I experienced the issue earlier on 9.9.8 but then decided to rollback to 9.9.6. Now I would like to stick to a more recent version and did some investigation.

Is there a workaround for this or is this a known issue?

Christoph

Same issue here. I posted in the beta area.

We are experiencing the same issue. Cannot connect from a 9.9.10 client to a remote 9.9.10 server using AD, but the local AD login works fine, and logging in remotely to 9.9.6 and earlier servers works as well.

Also noting that there are new AD settings (SPN and UPN) that auto filled themselves after upgrading. The help documentation has not been updated to include these new settings fields.

Hello,

after upgrading to 9.9.10, the AD login is not working anymore.

The server_log says

12.10.2022 11:44:45	Debug	Failed checking for WindowsIdentityInfo
12.10.2022 11:44:45	Debug	CheckLogin->AD authentication by token: WindowsIdentityInfo is null.
12.10.2022 11:44:45	Err	Logon error for AD : WindowsIdentityInfo is null. Switch to other identity type(?)

However, this issue seems to be related to remote clients only. Local clients can still login via AD users. Remote login is still possible for non-AD users.

I experienced the issue earlier on 9.9.8 but then decided to rollback to 9.9.6. Now I would like to stick to a more recent version and did some investigation.

Is there a workaround for this or is this a known issue?

Christoph

Christopher,

We have a new AD auth. Please read here:

https://www.visualcron.c...TML/manage_servers2.html 

Also, remove the HOST/ part from the SPN or UPN string when typing in the Principal name.

Hello Michael,

thanks for your reply.

the documenation you provided does not help me. Whichever setting I use on the remot client side does just raise up different errors like



The UPN and SPN fields on the server settings page "User/Login" are empty and write protected. However, I understand, that they should be filled automatically. Could you provide a more extensive documentation of this changed feature. Up to 9.9.6 it worked just fine, without any complicated settings...

I finally got it working again. Here is how i fxed it:

First of all: SPN login is not working at all.

The UPN and SPN settings are only filled if connected locally I tried changing settings via remote client (without AD login).

The UPN string that was provided in the local client could be inserted as Principal name for the identity type UPN identity on the remote client.

However, I tried to find information on this significant change in all relase notes from 9.9.7 to 9.9.10. This change seems not to have been announced.

Hope this helps anyone experiencing the same issue.

Regards,
Christoph

I'm only able to get this working if on the Client's manage servers settings, I choose SPN Identity and use HOST/<client machine FQDN>. However, since we are presenting the Visual Cron client through Citrix, this will not work if we have a delivery group with more than one citrix server.

I'm only able to get this working if on the Client's manage servers settings, I choose SPN Identity and use HOST/<client machine FQDN>. However, since we are presenting the Visual Cron client through Citrix, this will not work if we have a delivery group with more than one citrix server.

Does HOST/LOCALHOST work for you? It does in our environment, and I'm not sure either whether it could sidestep the Citrix issue nor what domain settings might prevent that configuration from working.

Thanks bweston, yes, that works!

I'm only able to get this working if on the Client's manage servers settings, I choose SPN Identity and use HOST/<client machine FQDN>. However, since we are presenting the Visual Cron client through Citrix, this will not work if we have a delivery group with more than one citrix server.

Does HOST/LOCALHOST work for you? It does in our environment, and I'm not sure either whether it could sidestep the Citrix issue nor what domain settings might prevent that configuration from working.

Smart thinking! Thanks for the contribution.