locked
LDAP/AD Integration Paremeters RRS feed

  • Question

  • After trying for a long time, I could use some help setting up LDAP/AD with an R Server I'm trying to use.

    I keep getting a 401 response (according to the logs and the admin tool's Test Configuration method). Its hard to tell if the 401 is for the QueryUser DN and Password OR for the user credentials I enter when prompted. I could use a bit more information (than is on the website) about what BindFilter and SearchFilter are doing. Particularity with the {0} notation. How does the system know what the LDAP user attribute is? We use Active Directory so I'm guessing its the userPrincipleName? I'm guessing the general flow is the user enters their username (which should be the configured userPrincipleName?) and password is verified using the QueryUser as being valid and inside the configured search base/search filter. So I'm guessing the 401 I get is either my QueryUser is not configured right (which I feel confident is not the case) or I dont understand the what the username should be and how it works with the configured filters.

    Any help would be appreciated. I'm still fairly new to LDAP and AD but have been working with more knowledgeable people. I'm trying to champion this product in my organization and LDAP integration is practically a necessity so I'm glad you support it.

    Here is my current config:

        "LDAP": {
          "Enabled": true,
          "Description": "Enable this section if you want to enable authentication via LDAP",
          "Values": [
            {
              "Host": "10.130.1.14",
              "UseLDAPS": "False",
              "SkipCertificateValidation": "True", 
              "BindFilter": "CN={0},OU=Users,DC=URBANSCIENCE,DC=NET",
              "QueryUserDn": "CN=MyUserName,OU=Users,DC=URBANSCIENCE,DC=NET",
              "QueryUserPasswordEncrypted": false,
              "QueryUserPassword": "xxxxxxxxxxxx",
              "SearchBase": "OU=Users,DC=URBANSCIENCE,DC=NET",
              "SearchFilter": "CN={0}"            
            }
          ]
        }


     




    Thursday, February 2, 2017 4:50 PM

Answers

  • I figured it out!!!!

    It turns out AD will accept a binding in the form DOMAIN\sAMAccountName. So my final configuration looks like the following. I hope this is helpful for others. Huge learning experience for me. Thanks everyone!

    "LDAP": {
          "Enabled": true,
          "Description": "Enable this section if you want to enable authentication via LDAP",
          "Values": [
            {
              "Host": "10.130.1.14",
              "UseLDAPS": "False",
              "SkipCertificateValidation": "True", 
              "BindFilter": "OURDOMAIN\\{0}",
              "QueryUserDn": "CN=MyFullName,OU=Users,DC=URBANSCIENCE,DC=NET",
              "QueryUserPasswordEncrypted": false,
              "QueryUserPassword": "xxxxxxxxxxxx",
              "SearchBase": "OU=Users,DC=URBANSCIENCE,DC=NET",
              "SearchFilter": "sAMAccountName={0}"            
            }
          ]
        }

    Thursday, February 2, 2017 6:52 PM

All replies

  • The cn attribute is the Common Name of the user, also called the Relative Distinguished Name. It is the field labeled "Name" in the Active Directory Users and Computers MMC.

    However "cn={0}" doesn't make sense in an LDAP filter. To filter on all users with a value assigned to the cn attribute, you would use  the LDAP filter "(cn=*)", where "*" is the wildcard character. But since cn is a mandatory attribute, all users must have a value assigned. If you want to filter on all users in the base, the LDAP syntax filter would be "(&(objectCategory=person)(objectClass=user))". To retrieve a specific user in the OU you might use something similar to "(cn=Jim Smith)". But the filter you use depends on what you want to retrieve from AD.

    But my experience is with LDAP, not R Server. The LDAP syntax filters I have seen consist of clauses in parentheses combined with operators, "&" (And), "|" (Or), and "!" (the Not operator). I don't know the difference between BindFilter and SearchFilter. Also, I don't see where you specify the attribute values to be retrieved by your query.

    Edit: The more I think about it, {0} is a place holder. You should replace it with the actual common name of the user, for example the string "Jim Smith" (without the quotes).


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)



    Thursday, February 2, 2017 5:40 PM
  • This is the only reference I could find explaining BindFilter and SearchFilter:

    https://msdn.microsoft.com/en-us/microsoft-r/operationalize/security-authentication

    But the post says {0} is the user DN, which is misleading. DN is the full distinguished name. As I noted before, it should be the user common name (the value of the cn attribute). It makes me think that you don't need both filters. My guess is that if you know the full DN of the user, use BindFilter. If you need to query for the user, use SearchFilter.

    Not to make things overly complicated, but cn may not uniquely identify the user. The value of the cn attribute must be unique in the OU or container, but not in the domain. If you are only looking in OU, then it doesn't matter. And you don't need to worry about this if you have the full DN (and use BindFilter) as the DN uniquely identifies the object. Otherwise, if you are searching, if you search by cn, not only is not unique, but you could retrieve computers, groups, and other classes of objects, all of which use the cn attribute as their Relative Distinguished Name (in other words, their name in the OU or container).

    I hope this helps.

    Edit: I should add that the attribute in AD for the user principal name is userPrincipalName (not cn). The userPrincipalName attribute in AD is not even required to have a value, although it is required in the cloud.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Thursday, February 2, 2017 6:11 PM
  • Hello,

    Make sure that a value, any value, is defined for the userPrincipalName in the Active Directory Service Interfaces Editor or authentication will fail.

    Thanks.

    Thursday, February 2, 2017 6:17 PM
  • Thanks for the information! That confirms a lot of my suspicions.

    I was able to poke around with the configuration a bit more. It "seems" like the {0} will get populated with whatever username the end user enters when prompted (ie. they get prompted for a username. This username is available using {0}).  So, I updated my configuration to the following (for testing). This way the user enters there username (which they are used to doing for our other application). BUT, I hard coded (for testing) my actual full dn in the bind filter. This worked :) but obviously its not what we really want as I'm the only one that can authenticate.  I tried removing the bind filter....errors. So I guess, the search filter is used to find the user in the system and then (ideally) we could use attributes of that found user (besides {0}) in the BindFilter. I guess this wouldn't be a (big) issue if a user's sAMAccountName matched the cn or something. But that's not how our organization has it configured. Seems like there should be some extra parameters (as I'm used to seeing in other LDAP systems).

    I realize you are an LDAP (not R Server) expert, but someone might be able to give some extra insight. Maybe there are some undocumented parameters or something. Or maybe I'm not thinking about it correctly. My understanding is that a "BindFilter" needs to be a full dn for a user.

     "LDAP": {
          "Enabled": true,
          "Description": "Enable this section if you want to enable authentication via LDAP",
          "Values": [
            {
              "Host": "10.130.1.14",
              "UseLDAPS": "False",
              "SkipCertificateValidation": "True", 
              "BindFilter": "CN=MyFullName,OU=Users,DC=URBANSCIENCE,DC=NET",
              "QueryUserDn": "CN=MyFullName,OU=Users,DC=URBANSCIENCE,DC=NET",
              "QueryUserPasswordEncrypted": false,
              "QueryUserPassword": "xxxxxxxxxxxx",
              "SearchBase": "OU=Users,DC=URBANSCIENCE,DC=NET",
              "SearchFilter": "sAMAccountName={0}"            
            }
          ]
        }

    Thursday, February 2, 2017 6:38 PM
  • Verified. Thanks for the suggestion though. I updated Richard Mueller's replies with a bit more information I uncovered.
    Thursday, February 2, 2017 6:38 PM
  • I figured it out!!!!

    It turns out AD will accept a binding in the form DOMAIN\sAMAccountName. So my final configuration looks like the following. I hope this is helpful for others. Huge learning experience for me. Thanks everyone!

    "LDAP": {
          "Enabled": true,
          "Description": "Enable this section if you want to enable authentication via LDAP",
          "Values": [
            {
              "Host": "10.130.1.14",
              "UseLDAPS": "False",
              "SkipCertificateValidation": "True", 
              "BindFilter": "OURDOMAIN\\{0}",
              "QueryUserDn": "CN=MyFullName,OU=Users,DC=URBANSCIENCE,DC=NET",
              "QueryUserPasswordEncrypted": false,
              "QueryUserPassword": "xxxxxxxxxxxx",
              "SearchBase": "OU=Users,DC=URBANSCIENCE,DC=NET",
              "SearchFilter": "sAMAccountName={0}"            
            }
          ]
        }

    Thursday, February 2, 2017 6:52 PM
  • Glad you figured it out. The sAMAccountName is the "pre-Windows 2000 logon" name, is required in AD, and uniquely identifies the user (and the object).

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Thursday, February 2, 2017 7:31 PM
  • In the event that you run into any connection issues when configuring R Server for Active Directory/LDAP,  we recommend you run ldp.exe tool to search the LDAP settings and compare them to what you’ve declared in appsettings.json. You can also consult with any Active Directory experts in your organization to identify the correct parameters.
    Thursday, February 2, 2017 10:15 PM
  • Thanks this worked for me.  Make sure you change MyFullName to the user name that you are using.


    Friday, March 24, 2017 6:41 PM
  • Can we bind to a AD Group..?? meaning only users in that Group will be able to access..?

    in my case the Group is also in the same OU like normal users.

    Regards,

    Sai

    Wednesday, October 25, 2017 2:59 PM