User Accounts
A user account is an object in Active Directory and is a Security Principal, allowing for authentication and authorization. We can use Active Directory Users and Computers (ADUC) to manage accounts. Kerberos is used for user authentication, so it's important which username from AD is used.
Each object in AD has several different names (Naming Attributes - ways to refer to or identify the object). IDs are used for linking, so other names can be changed without affecting various connections. Possible forms of object names, along with those specifically for user accounts:
- Relative Distinguished Name (RDN) - relative LDAP name within a container (Organizational Unit), for users it's the Common Name (CN), attribute
cn, examplebouska - Distinguished Name (DN) - globally unique LDAP name, contains RDN and object location within AD hierarchy, attribute
distinguishedName, exampleCN=bouska,CN=Users,DC=company,DC=local - Canonical Name - equivalent to DN in a different notation, it's a constructed attribute (created during query)
canonicalName, examplecompany.local/Users/bouska - Name - same as Common Name (CN), attribute
name - Security Identifier (SID) - unique user identifier, used for Kerberos and group membership, attribute
objectSid - Globally Unique Identifier (GUID) - unique object identifier, attribute
objectGUID
Active Directory uses three keywords in the DN name according to the LDAP standard: CN - Common Name, OU - Organizational Unit, and DC - Domain Component. In contrast, Canonical Name uses DNS format.
A user account has two possible types of login names (Logon Name), which are also Naming Attributes:
- sAMAccountName - Security Accounts Manager (SAM) Account Name
- also referred to as Pre-Windows 2000 Name
- uses the format
Domain\sAMAccountName, which is called NetBIOS Logon Name - maximum length is 20 characters
- unique within the domain and mandatory
- stored in the
sAMAccountNameattribute
- User Principal Name (UPN)
- referred to as Internet-style login name and is based on RFC 822
- consists of two parts, UPN prefix - user login name and UPN suffix - DNS domain name, connected by the
@character, examplelogon.name@company.local - maximum length is 64 characters
- unique within the forest and optional
- stored in the
userPrincipalNameattribute
User Principal Name (UPN)
Because things around UPN aren't entirely simple, let's look at them in more detail.
Microsoft started using UPN for domain users in the era of Windows 2000. It was supposed to be the primary login name that the user should use. Its form is shorter than Distinguished Name, and Microsoft's idea was that it would be the same as the email address (which in practice can simplify work for an attacker who only needs to guess the password, not the name), making it easier for users to remember. Unlike DN, it's also not dependent on moving to a different container or renaming the domain (the suffix doesn't have to match the domain). Nevertheless, I would say that even in combination with Windows Server 2012 and Windows 8, NetBIOS Logon Name is still widely used.
As the UPN suffix, the DNS name of the current and root domain is offered by default, but we can add an alternative domain name (essentially any string in DNS format) created by the administrator within the forest. Management is done using Active Directory Domains and Trusts, where we right-click on the same-named item and select Properties.
In connection with sAMAccountName, Microsoft recommends using the same beginning of UPN. But because there's a 20-character limit, in many cases, the UPN might use the first name and surname, while sAMAccountName uses the first letter of the name and surname.
Microsoft states in some materials that a user account always has both sAMAccountName and User Principal Name. Others confirm what we can verify in practice, that only the sAMAccountName attribute is mandatory, not userPrincipalName. Still, there's interesting information that I found only in unofficial materials. That is, UPN always exists, even if the userPrincipalName attribute isn't filled. Some talk about default UPN, some about implicit UPN, but the result is the same (and maybe it's not even UPN, but simply a different notation of sAMAccountName). Whether we have UPN filled or not, we can use username@DnsDomainName, where username is sAMAccountName and DnsDomainName is the DNS name of the domain where the account is located. If we fill in the userPrincipalName attribute, we define another explicit UPN, where we can use any username and suffix (which we must register within the forest).
What username is is very important for Kerberos authentication. Kerberos uses the term Client Name (Principal Name) and Realm, we often also encounter the use of User Principal Name. In an AD domain, Realm equals DNS domain, and through practical experiments, I've verified that Client Name equals sAMAccountName. As a result, this corresponds to the implicit UPN.
To verify the above in practice, I performed the following tests. In a domain with DNS name company1.local and NetBIOS name company1, I created a UPN suffix test and a user with the following names:
distinguishedName CN=userwithalongnamehere,CN=Users,DC=company1,DC=local sAMAccountName userwithalongnameher cn userwithalongnamehere name userwithalongnamehere userPrincipalName userwithalongnamehere@test
Then I tried to log in. The following names passed:
COMPANY1\userwithalongnameher- NetBIOS logon nameuserwithalongnamehere@test- specified UPNuserwithalongnameher@company1.local- implicit UPNcompany1.local\userwithalongnameher- using DNS domain name in NetBIOS login
Login failed for:
COMPANY1\userwithalongnamehereuserwithalongnamehere@company1.localcompany1.local\userwithalongnamehere
In Microsoft's description, I read the following about logging in. When we use sAMAccountName for login, we also specify the domain where the account is located (or the current one is used). When using UPN, the domain isn't clear (we only enter the suffix, which doesn't have to correspond to the domain), so it's first searched in the current domain, if the UPN isn't found, the global catalog is used and the domain where the account is located is searched.
During experiments with various logins, I also captured communication. To make everything more interesting, I was logging in from another trusted domain (it was company2.local). When the client tries to log in, i.e., obtain a TGT, it sends the login credentials we entered in the request (see examples above). If we successfully obtain a ticket, it always contains the DNS domain and the username sAMAccountName.
If we enter the form domain\name, the name is searched for (compared with the sAMAccountName attribute) within the domain (whether it's NetBIOS or DNS). Thus, in the KRG-AS-REQ packet, Client Name = name, Realm = domain is used.
If we enter name@domain (i.e., UPN), it's first searched in the local domain, using Client Name = name@domain (compared with the userPrincipalName attribute), Realm = DNS name of the current domain. If not found, the DC searches using the global catalog to see if the UPN exists in another domain or if the suffix corresponds to another domain. If yes, it returns a reference to the domain. The client makes a new query with a different Realm and sends it to the DC from the reference.
User Information on the Workstation
On the workstation, we can use certain command-line commands to get information about the user. The first command is a query for any user in the domain:
C:\>net user bouska /domain The request will be processed at a domain controller for domain company.local. User name bouska Full Name Bouška Petr Comment Ing. Petr Bouška User's comment Country/region code (null) Account active Yes Account expires Never Password last set 1.3.2014 14:54:14 Password expires Never Password changeable 1.3.2014 14:54:14 Password required Yes User may change password Yes Workstations allowed All Logon script User profile Home directory Last logon 19.5.2014 16:24:41 Logon hours allowed All Local Group Memberships Global Group memberships *G Jabber IM *Domain Users The command completed successfully.
The second option is a range of different parameters of the well-known whoami command, which displays the currently logged-in user.
C:\>whoami /upn bouska@company.local C:\>whoami /fqdn CN=Bouška Petr,OU=IS,OU=Company,DC=company,DC=local C:\>whoami /logonid S-1-5-5-0-1835268 C:\>whoami /user /fo list USER INFORMATION ---------------- User Name: ok\bouska SID: S-1-5-21-2200232112-3866456066-1594429224-1223
Hodně informací se můžeme dozvědět i z jednoduchého výpisu systémových proměnných. Je zde vidět jméno počítače, autentizačního severu (DC), domény (NetBIOS i DNS) či uživatele. Ukázkový kousek výpisu:
C:\>set COMPUTERNAME=BOUSKAP LOGONSERVER=\\DC USERDNSDOMAIN=COMPANY.LOCAL USERDOMAIN=COMPANY USERNAME=bouska USERPROFILE=C:\Users\bouska windir=C:\WINDOWS
Service Principal Name (SPN)
Service Principal Name (SPN) is used in Active Directory, where it is stored in the servicePrincipalName attribute of an account. It is one of the fundamental elements of Kerberos authentication, along with the DNS service. SPN is a unique identifier for a service running on a server. In other words, it is the name by which a client uniquely identifies an instance of a service within the forest. Each service where we want to use Kerberos authentication must have an SPN registered on the account it uses to log in. One service can have multiple different SPNs, and similarly, one account can have multiple SPNs assigned to it.
SPN syntax is generally ServiceClass/Host:Port/ServiceName, but most often it is just ServiceClass/Host. The first part is the name that generally identifies the class of service, examples include ldap, GC, HOST, DNS, HTTP, TERMSRV, MSSQLSvc. For web servers, whether it is HTTP or HTTPS protocol, HTTP is used. The second part is the name of the computer where the service is running. Usually, FQDN (Fully Qualified Domain Name) is used, but if we access the service via NetBIOS name, we must use that. Similarly, in some cases, we need to add a DNS alias. Fortunately, we can register multiple SPNs. An example of an SPN for a web server is HTTP/www.company.local.
In Windows (from Windows 7 / Server 2008), we have a command-line tool setspn, which is used for viewing, setting, and deleting SPNs in Active Directory. For certain operations, we need the appropriate permissions. We can verify the existence of a specific SPN or search for all SPNs for a given service or server. Here are a few examples of searching using setspn:
setspn -Q HTTP/server.company.local setspn -Q HTTP/* setspn -Q */server.company.local setspn -Q */*
If we want to search within the entire forest, we need to add the F switch.
setspn -F -Q HTTP/server.company.local
Another example shows the registration of a new SPN for a web server to the webserver account.
setspn -S HTTP/www.company.local company\webserver
Links
- User accounts
- Service Principal Name
skvělý článek. děkuji