Sophos Central Endpoint and SEC: Computers fail/hang on boot after the Microsoft Windows April 9, 2019 update. Please follow knowledge base article 133945
Learn about the Benefits of Multi-Factor Authentication (MFA). Turn your MFA on now!
We'd love to hear about it! Click here to go to the product suggestion community
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 contact.pl contact.pl:
Yes, exactly. My problem was also caused by this.
In reply to Michal Bartos:
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 email@example.com 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:
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.
Better ping the Case ID to FloSupport
But can you explain to me in more details those implementation reasons?
I am just curious, want to expand my knowledge.
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 ...
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".
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: UserA@contoso.com). 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 (contoso.com). 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 firstname.lastname@example.org, but XG is expecting email@example.com.
Try to download new VPN profile from the user portal and it should work.
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!!!
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.
I think all Sophos Customers are compliant this issue.
@sachingurung any idea or fix ?
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 firstname.lastname@example.org, other instead, no
The domain is the same, the user configuration too, so is very strange that one logged succesfully and other one no
Apologies for this inconvenience. Have you already raised a case with our team so that further investigation can be performed?
Nicola Losco 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.
To follow up regarding Ste 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."