Special OS, AD Accounts and SQL Server



Windows has a few special built-in accounts and groups.  And, same goes for Active Directory.

Unfortunately, how to reference those accounts within SQL Server is not always in reach.


Account & Group Names

Sam Account

The SAM Database is the database that houses the local computer’s users and groups.


Account Name What does it mean? Account Name  Create Login
Everyone All interactive, network, dial-up, and authenticated users are members of the Everyone group  \EVERYONE  CREATE LOGIN [\Everyone]
Authenticated Users The Authenticated Users identity Any user accessing the system through a logon process has the Authenticated Users identity.  NT AUTHORITY\Authenticated Users CREATE LOGIN
[NT AUTHORITY\Authenticated Users]




Active Directory Domain

Account Name What does it mean? Account Name  Create Login
Domain Users <domain-name>\Domain Users CREATE LOGIN [<domain-name>\Domain Users]





Authenticated Users

Randy Franklin Smith

  1. Understanding the Authenticated Users Group

    Microsoft created the Authenticated Users group in response to fears that Anonymous logons could gain access to objects for which Everyone (another special security principal) has access. I don’t recommend using the Authenticated Users group for controlling permissions because it includes local accounts, which are a bad practice to use because you can’t centrally manage them at the domain level, and they use NT LAN Manager (NTLM) authentication rather than the stronger Kerberos. Also, the membership of Authenticated Users changes dynamically when you create a trust to another domain. When you want to give all users in a domain access to a resource, I recommend that you use the Domain Users group, which limits membership to the domain. If you need to give all users in a forest access to a resource, create a universal scope group called Forest Users and add each domain’s Domain Users group as a member.




  1. Windows Built-in Users and Default Groups

    A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer. Users can perform tasks such as running applications, using local and network printers, shutting down the computer, and locking the computer. Users can install applications that only they are allowed to use if the installation program of the application supports per-user installation.




  1. Microsoft – TechNet Magazine
    • TechNet Magazine > Tips > Windows Server 2008
    • Windows Server 2008 > Understand Implicit Groups and Identities
  2. WeaselFire Ramblings
    • Everyone isn’t everyone
  3. Exploit Database
    • Ubisoft Uplay 4.6 – Insecure File Permissions Privilege Escalation
  4. Varonis.com
    • Rob Sobers
      • The Difference Between Everyone and Authenticated Users
  5. Windows IT Pro
    • Jan De Clercq
      • What’s the scope of the built-in Authenticated Users group in a multi-forest Active Directory (AD) environment?
    • Randy Franklin Smith
      • Understanding the Authenticated Users Group
  6. Stack Overflow
    • StackExchange.com
      • Windows groups and permissions: Authenticated Users group meaning
  7. ss64.com
    • Windows Built-in Users and Default Groups

Microsoft – SQL Server – Authentication Error – Cannot generate SSPI context. (Microsoft SQL Server, Error: 0)

Another day, Another (computer) problem.

One does not need to wonder much to determine why IT people have issues with “General Grumpiness”. But, let us leave that for another day.

User emailed asking if the database server is down… I checked a bit and the server appeared up.

User emailed me the exact error message “Cannot generate SSPI context. (Microsoft SQL Server, Error: 0)”.

I tried the following:

  • Changed the “MS SQL Server” service from AD Domain Account to “Local System”, back and forth a few time
  • Used “setspn” to review spn listings
         setspn -L <server-name>
         setspn -L <AD Domain Account> | find “<server-name>”
  • Thought about using klist or/and kerbtray
  • But, could not shake the need to try “w32tm /resync”.  First time I tried it, it failed with a bunch of errors.  The second time, accessed the service palette to stop and restart “Windows Time” (w32time).  And, then issued “w32tm /resync”.
  • Viola — Now user can authenticate using Windows Authentication

Finding the solution through the means detailed above works, but a bit more scientific path would be to enable Kerberos “Event Logging”.

How to enable Kerberos event logging

Enabling Kerberos Event Logging on a Specific Computer

Start Registry Editor.

Add the following registry value:


            Registry Value: LogLevel
            Value Type: REG_DWORD
            Value Data: 0x1

If the Parameters subkey does not exist, create it.

Please remove this registry value when it is no longer needed so that performance is not degraded on the computer. Also, you can remove this  registry value to disable Kerberos event logging on a specific  computer.

The setting will become effective  immediately on Windows Server 2008, on Windows Vista, on Windows Server 2003, and on Windows XP.

For Windows 2000, you must restart the computer.

Review Event logging

Once the registry change is effected, issue the client command\request again and start reviewing the Windows Event Viewer:

For example, on a computer that has this error.

Error:- 0x25 KRB_AP_ERR_SKEW

A Kerberos Error Message was received: on
logon session
Client Time:
Server Time: 22:26:27.0000 11/19/2010 Z
Error Code: 0x25 KRB_AP_ERR_SKEW
Extended Error:
Client Realm:
Client Name:
Server Realm: LAB.COM
Server Name: LDAP/LABDC04.LAB.com/lab.com
Target Name: LDAP/LABDC04.LAB.com/lab.com@LAB.COM
Error Text:  File: 9 Line: d86 Error Data is in record data.


AD Server (LABDC04) was contacted and it returned error 0x25 KRB_AP_ERR_SKEW.

Using Google came upon MS’s own explanation:

Authentication Errors are Caused by Unsynchronized Clocks


Kerberos authentication relies on the date and time that are set on the KDC and the client.  If there is too great a time difference between the KDC and a client requesting tickets, the KDC cannot determine whether the request is legitimate or a replay. Therefore, it is vital that the time on all of the computers on a network be synchronized in order for Kerberos authentication to function properly.

Clock skew can be easily diagnosed by reviewing the information in the System log.