Announcement

Collapse
No announcement yet.

LDAP priority and weight based on location?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • LDAP priority and weight based on location?

    Is there a way for Domain Controllers to have different weights and priorities within SRV records on Windows DNS based on location?

    For example. Two locations, New York and London, each has a Domain Controller (NewYorkDC and LondonDC) that runs DNS, as well

    In the DNS in New York, I want the domain SRV record for NewYorkDC in the forward lookup : _msdcs\dc\_tcp to have a priority of 0 and weight 100, while I want the record for LondonDC to have a priority of 10 and weight of 100.

    However in the DNS in London, I want the reverse. I want the NewYorkDC record to have a priority of 10 and weight of 100 and the record for LondonDC to have a priority of 0 and weight of 10.

    Essentially, I want the local DNS to have the SRV record of the local DC to be 0 while all others have a priority of 10.

    I know that you can change the registry values: LdapSrvPriority and LdapSrvWeight on the Domain contollers, but this will be a global change, not the site specific type of change I'm looking for.

  • #2
    Re: LDAP priority and weight based on location?

    Not sure what your goal would be with this?
    Marcel
    Technical Consultant
    Netherlands
    http://www.phetios.com
    http://blog.nessus.nl

    MCITP(EA, SA), MCSA/E 2003:Security, CCNA, SNAF, DCUCI, CCSA/E/E+ (R60), VCP4/5, NCDA, NCIE - SAN, NCIE - BR, EMCPE
    "No matter how secure, there is always the human factor."

    "Enjoy life today, tomorrow may never come."
    "If you're going through hell, keep going. ~Winston Churchill"

    Comment


    • #3
      Re: LDAP priority and weight based on location?

      This is my issue:

      I use Checkpoint Securemote as my remote access solution.

      Each remote office (i.e. London, Paris, etc) has a firewall and that firewall is configured to 'protect' a set of IPs.

      Each of these remote offices also has a Domain Controller.

      Everytime a VPN client needs to access a device behind a specific firewall, it has to authenticate against that firewall.

      The laptops that are used by people that are in and out of the office are part of the domain.

      When not in the office, we use the VPN client to connect to the network. After the laptop first authenticates to the VPN, it is assigned a DNS, based on which remote firewall it initially connected to. The laptop then, sends out a DNS request for the SRV records, specifically the _ldap._tcp.dc._msdcs.mydomain.com record. The standard response is all the DCs within the Active Directory at equal weights and priorities. Once the client receives that response, the next step, is for the laptop to then send out LDAP packets to each and every one of those DCs. So, if I have 6 DCs in 6 remote locations, I get 5 additional prompts for authentication.

      If I manually set priorities, I can manage what DC the client contacts after the initial SRV request, and then based on the IPs within Sites and Services, they can be directed to the proper local DC for any further communication. However, this is a global change and the one change will replicate to the remote DNS, so it will only correct the issue for one site.

      So, my goal is to stop the laptop from having to authenticate against multiple firewalls. The reason it is challenged by multiple firewalls is because the laptop is trying to contact all the active DCs in the network. The reason the laptop is trying to contact all the DCs is because of the SRV record that is returned by the DNS request. I've approached this from a variety of different angles, and my current investigation is trying to manage the SRV record.

      I appreciate any ideas or tips you might have

      Incidentally, this doesn't just effect the remote connectivity example (that is just the one that is most annoying to the user). The same thing happens to machines on the LAN. After the DNS request, the machine sends packets to all the different DCs, because of the SRV record returned.
      Last edited by robrien; 6th April 2009, 20:46.

      Comment


      • #4
        Re: LDAP priority and weight based on location?

        I believe you are looking for this

        http://technet.microsoft.com/en-us/l...2.aspx#E0HE0AA

        search for Weight

        real answer

        To change the weight for DNS SRV records in the registry
        1. In the Run dialog box, type regedit, and press ENTER.
        2. In the registry editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Pa rameters.
        3. Click Edit, click New, and then click DWORD value.
        4. For the new value name, type LdapSrvWeight and press ENTER. (The value name is not case sensitive.)
        5. Double-click on the value name you just typed to open the Edit DWORD Value dialog box.
        6. Enter a value from 0 through 65535. The default value is 100.
        7. Choose Decimal as the Base option.
        8. Click OK.
        9. Click File, and then click Exit to close the registry editor.
        This will in DNS like an MX record the lower the number the more important it is.. the higher the number the lower importance.

        Enjoy

        Comment


        • #5
          Re: LDAP priority and weight based on location?

          Given that you have a central VPN server you can do the following:
          1) assign the IP range of VPN clients to an AD site
          2) make sure CLDAP (UDP/389) is allowed only to the DC in the AD site local to the VPN concentrator.

          If the client can't issue LDAP Ping to a DC, it will not try to authenticate to it and will move on to the next one in the list.

          If each site has VPN concentrator, things start to get uglier...

          Before talking about options, I want to make sure the process of locating a DC is clear:

          1. When a client boots, it tries to fetch the last cached AD site from the registry (HKLM\System\CCS\Services\netlogon\Parameters -> DynamicSiteName)
          2. if the value exists, the client will first query for site-specific SRV record for the cached AD site. If one of the DCs in the cached AD site responds, the client will refresh the cache and will update its AD site (if it changed)
          3. If the value does not exist or none of the DCs in the cached AD site are accessible, the client will query for global SRV records (the ones you are talking about) and will try to issue LDAP Ping to the DCs from the list returned by DNS. The fastest to answer will be used and the client will try to figure out it's AD site and refresh the cache.

          Possible approaches:

          1) Do not block DCs from remote sites on in the firewall

          2) By controlling CLDAP (UDP/389) on the firewalls, you can make sure that CLDAP is allowed for VPN clients only to the AD site the VPN concentrator is located. This will result in client always picking the DC in the correct site

          3) Warning: ugly hack. This disables the client's ability to dynamically determine it's AD site If the client laptop is supposed to be associated to the same AD site when either on LAN or using VPN, you can hard-code the AD site for the client, which will result in querying the site-specific SRV records first instead of global. This can be done by setting SiteName value under the same key as DynamicSiteName (do not edit DynamicSiteName as it is managed by netlogon and will be overridden)

          4) Create a dedicated authentication AD site that is accessible from all the sites and make sure its DCs have higher priority (NOT weight. see http://technet.microsoft.com/en-us/l.../cc787370.aspx for details). Notice that this will result in all non-site specific queries going to this DC - something that I would not recommend.

          Btw, is authentication to remote site's firewall required when on LAN ?
          Last edited by guyt; 12th April 2009, 08:30.
          Guy Teverovsky
          "Smith & Wesson - the original point and click interface"

          Comment


          • #6
            Re: LDAP priority and weight based on location?

            hpyjack,

            Thanks for the reply. Unfortunately, since my DNS boxes are integrated with each other, the change to the weight or the priority at the server, will replicate to all the DNS, globally. So, if I set the priority of the NewYorkDC to be 10, and the LondonDC to be 10 via their registry keys, then all the DNS througout the world get the update and both are the same priority again.

            I was hoping for a way to limit the NewYorkDC weight of 10 to be only set on the New York DNS.
            Last edited by robrien; 14th April 2009, 15:36.

            Comment


            • #7
              Re: LDAP priority and weight based on location?

              guyt,

              Thank you for the detailed reply.

              Each site does have a VPN concentrator, so that's why it's been so messy.

              The explanation of the process of locating a DC was very helpful. After reading your explanation, I did some more testing. In my environment, the DynamicSiteName key was coming and going. Sometimes it would retain the site name after reboots, sometimes it would disappear. It seems to have something to do with which interfaces are active and connected at the time of shutdown and restart.

              I created the SiteName registry key and set it's value to the proper site and the system acts as expected. It only requests the _ldap._tcp.SiteName._sites.dc._msdcs.myDomain SRV record and does not initiate connections with the other sites and firewalls.

              I understand that setting this registry key will disable the client's ability to dynamically determine it's AD site, however, for 99% of our users, this won't be such a bad thing.

              Comment


              • #8
                Re: LDAP priority and weight based on location?

                As a side note you can set the value of this registry key in a site level GPO so that it always get sets for the client machines. Since GPO's are applied to objects in their paths, even if a client authenticates to the wrong DC, the site level GPO for that client's site will create the registry entry which will force the client to authenticate to the correct site DC on the next logon.

                You might wait to see if Guy responds to this suggestion to give his opinion since he seems to be the resident in depth expert on AD operations.

                Comment


                • #9
                  Re: LDAP priority and weight based on location?

                  Originally posted by joeqwerty View Post
                  As a side note you can set the value of this registry key in a site level GPO so that it always get sets for the client machines
                  This might help deploying the registry setting for clients when on LAN, but otherwise it's a chicken & egg situation - if the client knows its site, the correct site will be hard-coded. If it doesn't (or is in the process of discovering it as in the case above), it wouldn't

                  Not that it can't be done, but it does require configuring the GPO for ALL existing AD sites to prevent issues with traveling users: user with primary site A visits site B and returns. In this case 2 GPOs have to be defined for both sites.

                  If you ask me, I'd be very careful with this setting and would deploy it only to laptops. If the VPN client allows running scripts, this is probably the place I'd push the setting.
                  Guy Teverovsky
                  "Smith & Wesson - the original point and click interface"

                  Comment


                  • #10
                    Re: LDAP priority and weight based on location?

                    Thanks again guyt. Currently, I plan on doing it by script, and only to the laptops of people that report the multiple authentication challenges.

                    Comment


                    • #11
                      Re: LDAP priority and weight based on location?

                      I assume, with regards to sites, that these boundaries will come into effect first when clients do lookups?
                      cheers
                      Andy

                      Please read this before you post:


                      Quis custodiet ipsos custodes?

                      Comment


                      • #12
                        Re: LDAP priority and weight based on location?

                        Andy,

                        I'm not quite sure what you are asking.

                        The client machines do not need to contact the remote sites. The only traffic destined for the remote sites is the cldap traffic generated after the SRV record returned by the DNS lists all available DCs. If the client is not a member of the domain there is no need to reach the remote sites, therefore no requirement to authenticate.

                        So, general nslookups don't cause the traffic. Only the client trying to reach each DC from the SRV record cause the traffic.

                        Comment


                        • #13
                          Re: LDAP priority and weight based on location?

                          Hi,

                          I was looking for confirmation along the lines of (in a very generalised way):
                          A client machine looking for ldap will look at its local site first, determining based on weight/priority and then further afield.
                          Changing the priority of one box in another site will not make it higher priority for all machines on the domain so that they skip the site boundary
                          (hope I make sense!)
                          cheers
                          Andy

                          Please read this before you post:


                          Quis custodiet ipsos custodes?

                          Comment


                          • #14
                            Re: LDAP priority and weight based on location?

                            Andy,

                            I think I understand what you are asking.

                            Yes, a client machine will look for it's local site first. But, from what I understand from GUYT it determines it's local site by looking at the value of the registry key HKLM\System\CCS\Services\netlogon\Parameters -> DynamicSiteName. If this does not exist it requests the names and priorities of all the available DCs in the entire AD via a DNS request and queries those to determine what site it belongs to. It will contact each DC based upon it's weight and priority

                            By default, all weights and priorities are equal, so the default action is to contact each DC. I can manually change the priority value for a specific server in the DNS or there is a registry key I can set on the DC, itself, to change that priority. However, my DNS replicates with each other so that they have the same tables, so any change I make in one DNS will replicate to the others.

                            For example, if I set the priority for the NewYork DC to be the highest on the NewYork DNS, then that change will eventually be replicated on the remote DNSs. So the remote client (and all other clients that querey the DNS) will get a DNS record from the London server with the NewYork DC as the highest priority.

                            That's the direction I took with my initial question. i was looking for a way to change server priority on a regional level, instead of a global level. It doesn't appear as if this is possible. That is why we don't the rode of looking into the SiteName keys.
                            Last edited by robrien; 7th May 2009, 21:47. Reason: correcting my grammar

                            Comment

                            Working...
                            X