Results 1 to 8 of 8
  1. #1
    Untangle Ninja
    WebFooL's Avatar
    Join Date
    Jan 2009
    Location
    Sweden (Eskilstuna)
    Posts
    5,244

    Default userPrincipalName instead of sAMAccountName?!

    So we are swapping to CaptivePortal with "Any OAuth Provider" configured.
    We want just "Microsoft Account" OAuth but that option looks to be broken so activating "Any OAuth Provider" and then modifying the pickpage.html so only the "Microsoft Account" option is visible.

    OK step one done!

    Now to the fun part.
    Once Authenticated with the session is tagged with "Username" namn.lastname@domain.com (userPrincipalName) in the AD instead of the xxxnamlas (sAMAccountName) so Directory connector will not match the user to its group memberships as it only seams to be looking at the sAMAccountName attribute.

    So none of our group rules works. (That sucks as we only have group rules)

    Is this a known issue or design choice?

    Any quick fixes ?

  2. #2
    Untangle Ninja
    WebFooL's Avatar
    Join Date
    Jan 2009
    Location
    Sweden (Eskilstuna)
    Posts
    5,244

    Default

    If we connect the Directory Connector to the Azure AD instead the local AD or connect to both would that work.

    Or not..
    https://github.com/untangle/ngfw_src...sAMAccountName

    Looks like that also looks after sAMAccountName

  3. #3
    Untangle Ninja
    WebFooL's Avatar
    Join Date
    Jan 2009
    Location
    Sweden (Eskilstuna)
    Posts
    5,244

    Default

    Looks like one can configure azure ad to include sAMAccountName
    ex:
    https://docs.microsoft.com/en-us/ans...ad-claims.html

    Would that work or will Untangle still take userPrincipalName form the Oauth respons?

    This looks like the code handling that part.
    And dudes are ju just taking one attribute and forcing it in to another and hoping for the best?

    https://github.com/untangle/ngfw_src...apAdapter.java
    Code:
        /**
         * Get UID attribute name.
         *
         * @return fixed string "sAMAccountName".
         */
        @Override
        protected String getUIDAttributeName()
        {
            return (settings.getAzure() ? "userPrincipalName" : "sAMAccountName");
        }

    userPrincipalName is not sAMAccountName!!!
    So how is the sAMAccountName "fixed" in this code?

  4. #4
    Untangler mahotz's Avatar
    Join Date
    Jun 2010
    Posts
    36

    Default

    The Captive Portal OAuth stuff was a little tricky. The identity extraction is handled by a script running on our auth-relay server, which is where we get the callback from the provider on successful login. That operation also sends the client a new redirect that sends it back to the untangle. In that redirect is the client authcode. When we detect that, the untangle calls a script on auth-relay that uses the authcode to request the client identity from the provider. We extract the identity from the provider response and return that, or an ERROR message, which the Untangle uses to then send the final redirect to the original destination, or a failure message if anything goes haywire in that whole process.

    For Microsoft, we first try to get userPrincipalName from the provider response. If that isn't there, we look for displayName and return that. If neither are there, we return an error.

    So there is no easy way to change the behavior.

    However, if the Microsoft specific OAuth feature is broken, that's a problem and I'll certainly look into that!

    Mike

  5. #5
    Untangle Ninja
    WebFooL's Avatar
    Join Date
    Jan 2009
    Location
    Sweden (Eskilstuna)
    Posts
    5,244

    Default

    mahotz thanks for your response

    Well the problem is that the session get authenticated with userPrincipalName but Directory Connector can't look up group membership on userPrincipalName.

    So if you don't want to poke around with the Oauth stuff and have ppl adding sAMAccountName or displaynamne you can just fix so that Directory Connector can search the AD for group membership from userPrincipalName and/or sAMAccountName.

    Right now we can create a MFA Captive Portal with using Microsoft as authentication and having MFA Policy rules for "Network Logon" App id f8285e96-b240-4036-8ea5-f37cf6b981bb creating a policy demanding MFA login every connection and that works with all Untangles VPN solutions but this will be useless to us if the users don't get matched to there groups.

    So as a User of Directory Connector and Policy manager with most rules bases on group or username (sAMAccountName) suddenly getting userPrincipalName on the sessions is more than useless it is bad as they will not match any of our policy's and the are being blocked.


    I see two options:

    Option one:
    Modify your auth-relay side so first look for sAMAccountName then userPrincipalName and last displayName.
    Then update your wiki so that it includes instructions on how to adjust so that the response from Azure AD includes sAMAccountName.

    Option two:
    Modify Directory Connector Group lookup so it can lookup both sAMAccountName and userPrincipalName.
    Or just do a logical lookup form the userPrincipalName to get the sAMAccountName and set that to the session..



    So I don't agree with you that
    So there is no easy way to change the behavior.
    I see it as a responsibility that Untangle inc have to make sure we can use the product and that its modules work with one and another.

    To be clear in my mind the development of the auth-relay part should have notified the Directory Connector team and noticing them that sessions now also can have userPrincipalName in the Username" field. And having them evaluate if there component can use that.

    In short if this is fixed Untangle could drop adding MFA to every VPN protocol by it self. (Less code to manage)
    And just have a Instruction on how to add a Captive Portal that demands MFA form any of the Oauth providers you currently support.

    Hope you see the point that I am trying to make :-)

  6. #6
    Untangle Ninja
    WebFooL's Avatar
    Join Date
    Jan 2009
    Location
    Sweden (Eskilstuna)
    Posts
    5,244

    Default

    Or if you add more "Fields" so that userPrincipalName get its own field and the you can add a simple lookup function on all sessions where userPrincipalName has a value but usename is "null" and then add sAMAccountName there.

    I see just solutions but we have to agree that this is a problem first

  7. #7
    Untangler mahotz's Avatar
    Join Date
    Jun 2010
    Posts
    36

    Default

    When I said "no easy way", what I meant was we can't change the default behavior of a resource shared by our entire installed base without giving existing users a way to configure things such that it can be made to work the original way before the change was implemented. Customers that have for years been receiving principalUserName might be very upset if we suddenly start returning sAMAccountName first if it happens to exist.

    When we originally added OAuth to captive portal years ago, we thought of it from the perspective of simple identity, not network security. I believe the original product requirement only specified login using Facebook accounts, and maybe Google. I believe I added Microsoft all on my own. I tested it with my own personal Hotmail account. That's really all we were going after. Allow Captive Portal login with a Facebook account, and display the email address in reports.

    With all that said, and understanding your level of skill and expertise, I think I found a way to make it work for you right now. Understand this is not officially supported, but I think it will give you something to test. If it works the way you need, we can see about creating a product enhancement request for our product team to consider.

    I created a new version of our identity extraction script on the auth-relay server that you can use if you modify the Captive Portal handler.py script. Just find the line where we create uri_base with /cgi-bin/getClientToken, and change the name to /cgi-bin/getEnterprise token. That script behaves as suggested in your Option one. It will first try to return sAMAccountName, and then userPrinciplaName, and then displayName.

    Let me know how it goes.

    Mike

  8. #8
    Untangle Ninja
    WebFooL's Avatar
    Join Date
    Jan 2009
    Location
    Sweden (Eskilstuna)
    Posts
    5,244

    Default

    Thanks Mike!

    I will do some tests next week and give you feedback.
    But if this works i would solve my issue and i would add it to the "normal" handler.py and add inscructions in the wiki on how to configure Azure AD to return the right values.

    And if it works i would say that Untangle has support for MFA on any of its VPN solutions.

    1. Tunnel is establish with PKI/PSK etc.
    2. Authentication to get from VPN segment to any other segment is MFA over Captive Portal.
    You need to configure so you authenticate against Microsoft and there have MFA activated and create a custom security policy to force MFA ever x hour.

    In my mind this would be a killer setup and something that everyone should want to use.
    No need to add Radius rules or plugins to add MFA just go with what you have in your Untangle device!

    Again thanks for the help so far!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2