Announcement

Collapse
No announcement yet.

Services requiring Domain level accounts run locallay

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

  • Services requiring Domain level accounts run locallay

    We have an installation that we are supporting where the client company does not want to be dependent on AD or DNS in order to run an application.

    Basiclly this is a Database application that is "safety" critical. The application does not require AD/DNS, however because the servers are in a clustered configuration it calls for a Domain Level account in order to run.

    We have proven that you can run it with Local User accounts for each node in the cluster. If you try to keep the computer logged into the domain, and then use Local User accounts, the cluster forms just fine. The problem comes in when SQL tries to register the Service Principal Name. If you use a Local User account or even the LocalSystem account, it fails.

    What I am trying to solve, is hope for the best of both worlds. Provide for Domain level management, policies, etc, and keep the customer happy by running the services with local type logins that do not require contacting a domain controller/dns server.

    Any suggestions?

    V/R

    Brian

  • #2
    Is it W2K or W2K3 ?

    Do the nodes (computer accounts) register their SPNs correctly in AD ?

    Just trying to think loud: AD needs to know about the account that will be registering SPN. This means that server's local accounts have no chance to get access to AD. The only account AD is aware of is the machine account (this is Local System account) which by default has "Validated write to service principal name" permission.

    1. You can try to use "setspn.exe" from W2K3 support tools to manually register the service SPN and see if it resolves the problem.

    2. You can tweak the ACL to enable everyone to write the SPN (obviously this is security hole and will require enabling anonymous binds in W2K3, if I am not mistaken)

    3. Quick search in MSDN comes up with this:
    http://msdn.microsoft.com/library/de...s_its_spns.asp
    according to the article, service should be able to write it's SPN when running as LocalSystem account, though in this case the SPN must comply a certain standard (see the link for details). The failure to register SPN when running as LocalSystem can be a result of member server having incorrect FQDN (domain part of the hostname does not match the AD DNS name). Make sure the member server 's primary DNS suffix is the DNS name of the AD.

    Does the server have additional DNS suffixes configured ? (connection specific) and is it set to register dynamically in DNS ?
    Guy Teverovsky
    "Smith & Wesson - the original point and click interface"

    Comment


    • #3
      RE: Services requiring Domain level accounts run locallay

      Guy, it is a W2k3 installation, and I appologize if I did not make my situation clear on the first message.

      It is a 2 node cluster tied to a SAN. When the cluster configuration is left at the default installation, domain level account for the cluster service, domain level account for the SQL Server and SQL Agent account, and the Domain Controller available, all functions normally.

      2 domain controllers, 2 DNS servers.

      The client wants to eliminate the dependency on the Domain controller and run with Local User accounts on both nodes of the cluster while leaving the COMPUTERS logged into the domain. Thus far, I can get the Cluster service account to run in this mode by using a Local User account on both nodes, and it establishes the Cluster/IP/Network Name and Quorom with error.

      With regard to the SQL Service Accounts, If the computer is logged into the DOMAIN, and not logged in to local machine, then SQL fails to register the SPN when I use either the LocalSystem account or if I use a Local User account.

      Whenever the cluster is brought online either from a failover or just establishing it, it registers the SPN for the Virtual SQL Server.

      I have not tried the SetSPN utility yet. I am currently setting up a lab to duplicate the current configuration so that I can continue testing and not impact on service.

      Additional info, if both nodes of the cluster are logged into Local Computer logins, and the services are set for Local User for the cluster, and LocalSystem/Local User account on the individual nodes, then the cluster functions normally.

      We also discovered that if there is no DNS configured the cluster will not registered, however if you use a HOSTS file with the cluster names, etc in it then it establishes faster.

      It should also be noted that No matter what Microsoft says, the LMHOSTS file will work in W2K3. If the cluster names are placed in the LMHOSTS with the PRE# statement, and nothing in the HOSTS or in the DNS configuration, it will establish the cluster, even if the disable NETBios is selected in the TCP/IP properties.

      I will give the SetSPN a try in the lab as soon as it is up and working.

      Thanks,

      Brian

      Originally posted by Guy (aka Antid0t)
      Is it W2K or W2K3 ?

      Do the nodes (computer accounts) register their SPNs correctly in AD ?

      Just trying to think loud: AD needs to know about the account that will be registering SPN. This means that server's local accounts have no chance to get access to AD. The only account AD is aware of is the machine account (this is Local System account) which by default has "Validated write to service principal name" permission.

      1. You can try to use "setspn.exe" from W2K3 support tools to manually register the service SPN and see if it resolves the problem.

      2. You can tweak the ACL to enable everyone to write the SPN (obviously this is security hole and will require enabling anonymous binds in W2K3, if I am not mistaken)

      3. Quick search in MSDN comes up with this:
      http://msdn.microsoft.com/library/de...s_its_spns.asp
      according to the article, service should be able to write it's SPN when running as LocalSystem account, though in this case the SPN must comply a certain standard (see the link for details). The failure to register SPN when running as LocalSystem can be a result of member server having incorrect FQDN (domain part of the hostname does not match the AD DNS name). Make sure the member server 's primary DNS suffix is the DNS name of the AD.

      Does the server have additional DNS suffixes configured ? (connection specific) and is it set to register dynamically in DNS ?

      Comment

      Working...
      X