Synchronized User ID and username with domain name not working

I have my XG configured with AD authentication using SSO client. Everything works - each domain user gets what she/he is supose to get. Now when I try to use Synchronized User Id I cannot get it to work. What I see in authentication log is following:

- for SSO client - user name is sent as "samAcconuntName@domain name" which is properly matched to users imported from domain

- for Synchornized User Id - user name is sent as "samAccountName" and XG cannot find such user so authentication fails

My questions is following:

- can I force XG somehow to match "samAccountName" request to user "samAccountName@domain name"

- is there a way to force heartbeat to include domain name as well in packet



  • In reply to

    Yes, exactly. My problem was also caused by this.

  • In reply to Michal Bartos:

    Hello Michal,

    we have found that sAMAccountName have to be identical to UPN to make the login user successful. We have opened for this case a ticket at the Sophos support. In our opinion, this is an implementation error, because sAMAccountName may not always be identical to UPN name.

    You could check it in your MS AD - User Properties - Attribute Editor ( should be enabled Advanced Features in View submenu).



  • In reply to alda:

    (I am no Windows / AD Guru, so please be careful with this knowledge).

    Already mentioned this early, we are using the SAMAccountname for User ID. XG is checking against the SAMAccountname and looking in AD for it. Not the UPN.



    And i saw some special customers with this setup, but nobody could explain to me the reason between different UPN to SAMAccountnames in their AD. There was some kind of as UPN but the SAMAccountname was domain\name, which is pretty unique. Seems like this is some "Historical grown environment".


  • In reply to LuCar Toni:

    Hello LuCar,

    we are sadly confronted with the problem with a customer implementation of Synchronize Security ( Security Heartbeat too of course ) with many thousands of users in whose environment. And for many implementation reasons in this environment does not apply that sAMAccountName must be identical to UPN.

    As I mentioned we already have an open support ticket to this problem, so I can send you a ticket number to your PM.



  • In reply to alda:

    Better ping the Case ID to  

    But can you explain to me in more details those implementation reasons? 

    I am just curious, want to expand my knowledge. 

  • In reply to LuCar Toni:

    Hello LuCar,

    I do not know implementation details for this enviroment. We were asked by a customer to implement the Synchronize Security. And for this reason we can not finish our task. In my opinion the problem is not in the XG but in a Central end-point client. This client will accidentally send the UPN name instead of sAMAccountName if these two user attributes are not identical.

    That's all ...



  • In reply to alda:

    You can simply deactivate Synchronized User ID and use an alternative / Pre V17.5 User Authentication until there is a way to work with this feature for this customer. 

    The Point is, Synchronized User ID is not an Security Feature of the Synchronized Security Story. It is just another approach to simplify the authentication. 

    All "Security Features" of Synchronized Security will work without Synchronized User ID. 

    Here is a command "how to deactivate this feature".

  • In reply to

    Hi Pawel,


    I have same problem: Heartbeat Authentication Failed because of wrong credentials. Your post is the only one that make sense with my tests..

    My configuration is: in Domain Name field on the XG Active directory server definition I've set my local domain (eg: contoso.local)

    Active directory authentication queries for Firewall and VPN are working and, on XG, all Users are created with SAMAccountname + @contoso.local extension (eg: UserA@contoso.local)

    Instead I see that Heartbeat authentication that send to AD SAMAccountname + UPN extention (eg: That is clear on access_server.log. This is the reason for fails.


    Now to solved I've to change the Domain Name field on the XG Active directory server definition to my UPN extentioin ( I've done a test about and results are:

    Heartbeat works but ALL VPN clinet connections fails! 


    LuCar Tony say: Already mentioned this early, we are using the SAMAccountname for User ID. XG is checking against the SAMAccountname and looking in AD for it. Not the UPN.


    I'm really confused and worried about.

    Someone have any Idea how to fix this problem and WHY ALL AUTHENTICATION ARE WORKING WITH SAMAccountname + @contoso.local AND ONLY HEARTBEAT NOT ????

  • In reply to Ste:



    We had same issue, VPN connections now fail, because the users now need to download their VPN profiles again (because of the certificate change).

    Your user certificate still looks like user@contoso.local, but XG is expecting 

    Try to download new VPN profile from the user portal and it should work.

  • In reply to Michal Bartos:

    Thank You Michael,


    Thant is ok for a 10 user vpn Deployment. But I've more than 100 user spread all over the word.

    This is not a solution that make any sense!!!

  • In reply to Ste:

    I have very similar case, that is why I tested it but still not did it. :)

    So my heartbeat auth still doesn't work, because it will be too time consuming to replace all the user VPN profiles.

  • In reply to Michal Bartos:

    I think all Sophos Customers are compliant this issue.

    @sachingurung any idea or fix ?


    Thank you

  • In reply to Ste:

    Hi all, i have the same problem but with a little difference, as you can see in the image below some user are able to login with user@domain.local, other instead, no


    The domain is the same, the user configuration too, so is very strange that one logged succesfully and other one no




  • In reply to Ste:


    Apologies for this inconvenience. Have you already raised a case with our team so that further investigation can be performed?

     That is strange, there must be something different between the users who can vs can't authenticate. Further investigation will have to be performed into your environment.

    Please PM me with your case details so that I can follow up.


  • In reply to Ste:

    Hi Community,

    To follow up regarding  it was related to the known behaviour regarding: "UPN must be identical to sAMAccountName to make the login successful as the sAMAccountName is used by the XG Firewall and not the UPN."