Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

 

Pawel



This thread was automatically locked due to age.
Parents
  • After some research and reading access_server logs I found issue. In our AD env we are using multiple UPN prefixes for user authentication. When Endpoint is sending heartbeat message it is using UPN defined in AD account tab. If XG doesn't have this prefix configured under any AD server in field "domain name" request is rejected.

    My only complain is fact that in log viewer, XG is showing that user was received without any domain while actually reading acces server logs You can see which domain was attached to username in heartbeat message.

    Pawel 

  • 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: 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 ????

  • Hello,

     

    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 user@contoso.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 ?

     

    Thank you

  • 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

     

    Nicola

     

  • Hi  

    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.

    Thanks,


    Florentino
    Director, Global Community & Digital Support

    Are you a Sophos Partner? | Product Documentation@SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the 'Verify Answer' button.
    The Award-winning Home of Sophos Support Videos! - Visit Sophos Techvids
  • 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."

    Regards,


    Florentino
    Director, Global Community & Digital Support

    Are you a Sophos Partner? | Product Documentation@SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the 'Verify Answer' button.
    The Award-winning Home of Sophos Support Videos! - Visit Sophos Techvids
Reply Children
  • Hi all,

     

    This limitation should be fixed.

    I actually could successful test it. 

     

    My Setup:

       

     

     

    Basically a user with SAMA as sAMAccountname and UPN as UPN. 

    Hope you can follow me. 

     

    Now login via Windows. 

     

    Check the XG: 

     

    :) 

    __________________________________________________________________________________________________________________

  • Hi Luca,

     

    the issue isn't solved. I've same logs (wrong credentials) with same endpoint version as your post. 

    If you see the history of the tread what me and  have reported is that the problem occurs when UPN extention (your @lc.local) is different by domain name ( if your UPN Extention is @lc.com)

     

    Please check again

  • This limitation is still in the product. The Domain has to be present in XG.

     

    The limitation is no longer there in the latest endpoint releases. However we still need the UPN domain part to be identical to the domain configured on the XG, in order to match the right auth server. The endpoints will send the sAMAccountName as the username now and the domain part of the UPN as the domain. 

    So basically you now need to set the correct auth server for this domain. 

     

     

     

    *correct my initial statement*

    __________________________________________________________________________________________________________________

  • thank you Luca, now I know what I've to do in the next new configurations.

    What i suggest to you is specify this on the server XG configuration because Domain name should be different by UPN domain part.

  • I have another question.

    Is there a reason to have domain.local and domain.com in a AD and do not use it on XG as well? 

    You have to specify a domain name in XG for each AD server.

    So basically AD Server 1 = domain.local 

    If all your users use the UPN: user@domain.com, i would assume, you use domain.com on XG as well? 

    There "could be" a workaround if you use another AD server and use there domain.com. 

    This should be possible, but i would like to know, why you used domain.local in the first place? 

    I know, if you change this "now", all your user would be reinstalled. 

    __________________________________________________________________________________________________________________

  • my AD server domain name = domain.local

     

    BUT: as Microsoft Office 365 SSO configuration requirement my UPN is equal to SMTP and SIP. 

     

    • The userPrincipalName attribute must be in the Internet-style sign-in format where the user name is followed by the at sign (@) and a domain name: for example, user@contoso.com. All Simple Mail Transport Protocol (SMTP) addresses should comply with email messaging standards.

    In Office 365, the UPN is the default attribute that's used to generate the email address. It's easy to get userPrincipalName (in AD DS and in Azure AD) and the primary email address in proxyAddresses set to different values. When they are set to different values, there can be confusion for administrators and end users.

    It's best to align these attributes to reduce confusion. To meet the requirements of single sign-on with Active Directory Federation Services (AD FS) 2.0, you need to ensure that the UPNs in Azure Active Directory and your AD DS match and are using a valid domain namespace.

     

    https://docs.microsoft.com/en-us/office365/enterprise/prepare-for-directory-synchronization

     

    list another AD server with contoso.com as domain name should be only workaround and in a large environment make only confusion.

  • Solution is really create one server for each public domain (UPN suffix).

    In my case customer has 1 DC and 5 UPNs.

    Ex. customer has mycompany.prv FQDN domain and company for NetBios Name. Of365 Domains are mycompany.it; yourcompany.eu, dontcare.com.

    I created DNS CNAME:

    mycompany.mycompany.prv -> DC Name

    yourcompany.mycompany.prv -> DC Name

    dontcare.mycompany.prv -> DC Name

    ..

    Than inside XG you create your servers as many as your UPNs

     

  • Because XG is looking for the "correct" AD Server depending on the Domain Name.

    Basically you can authenticate vs XG with a username like "Bob".

    If you have multiple Domains, XG will attach each Domain and try to authenticate each AD Server with this username.

    For example: Domain.com and local.com

    If you have two DCs configured in XG, the authentication server will try bob@domain.com and bob@local.com 

    That is the "multi Domain Support" within XG.

    __________________________________________________________________________________________________________________

  • This is nonsense, hence the same user who authenticates both for VPN and Navigation purposes would be saved as two different unlinked objects.

    and then if the user logs into UserPortal and downloads configuration files for the VPN, which domain will be used? one randomly picked up?

  • XG uses SAM accounts and this isn't unique (NT Style...).

    Dan.john could exist in 2 differents domains.

    While UserPrincipalName is unique

     

    Ste said:
    and then if the user logs into UserPortal and downloads configuration files for the VPN, which domain will be used? one randomly picked up?

    This is a good question.

    I think it makes a query to all auth servers, by XG's servers order.