www.SAMURAJ-cz.com 

16.12.2017 Albína Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Kerberos část 2 - AD uživatelské účty a Service Principal Name

Pondělí, 16.06.2014 08:51 | Samuraj - Petr Bouška |
Druhá část seriálu o protokolu Kerberos, se zaměřením na Single Sign-On (SSO) v prostředí Microsoft Active Directory, naváže na první díl a nebude se věnovat Kerberosu, ale věcem okolo Active Directory Domain Services. Docela podrobně se podíváme na přihlašovací jména uživatelských účtů, tedy User Principal Name (UPN) a sAMAccountName. V závěru ještě popíšeme jména instancí služeb (Service Principal Name).

Uživatelské účty

Uživatelský účet je objekt v Active Directory a jedná se o Security Principal, takže umožňuje autentizaci a autorizaci. Pro správu účtů můžeme použít Active Directory Users and Computers (ADUC). Kerberos slouží k autentizaci uživatelů, takže je důležité jaké uživatelské jméno z AD používá.

Každý objekt v AD má několik různých jmen (Naming Attributes - možností jak na objekt odkazovat či jej identifikovat). Pro provázání se používají ID, takže ostatní jména můžeme měnit, aniž by se ovlivnili různé vazby. Možné formy jména objektu, spolu s těmi, které jsou speciálně pro uživatelský účet:

  • Relative Distinguished Name (RDN) - relativní LDAP jméno v rámci kontejneru (Organizational Unit), u uživatelů jde o Common Name (CN), atribut cn, příklad bouska
  • Distinguished Name (DN) - globální unikátní LDAP jméno, obsahuje RDN a umístění objektu v rámci AD hierarchie, atribut distinguishedName, příklad CN=bouska,CN=Users,DC=firma,DC=local
  • Canonical Name - obdoba DN v jiné notaci, jde o konstruovaný atribut (vytváří se při dotazu) canonicalName, příklad firma.local/Users/bouska
  • Name - je stejné jako Common Name (CN), atribut name
  • Security Identifier (SID) - unikátní identifikátor uživatele, používá se pro Kerberos a zařazování do skupin, atribut objectSid
  • Globally Unique Identifier (GUID) - unikátní identifikátor objektu, atribut objectGUID

Active Directory používá v DN názvu tři klíčová slova dle LDAP normy, jde o CN - Common Name, OU - Organizational Unit a DC - Domain Component. Oproti tomu Canonical Name využívá DNS formát.

Uživatelský účet má dva možné typy přihlašovacího jména (Logon Name), jsou to zároveň také Naming Attributes:

  • sAMAccountName - Security Accounts Manager (SAM) Account Name
    • označuje se také jako Pre-Windows 2000 Name
    • používá se zápis Domain\sAMAccountName, který se označuje jako NetBIOS Logon Name
    • maximální délka je 20 znaků
    • je unikátní v rámci domény a povinný
    • ukládá se do atributu sAMAccountName
  • User Principal Name (UPN)
    • označuje se jako Internet-style login name a je založen na RFC 822
    • skládá se ze dvou částí, UPN předpony (UPN prefix) - uživatelské přihlašovací jméno (User Logon Name) a UPN přípony (UPN suffix) - DNS doménové jméno, spojených pomocí znaku @, příklad logon.name@firma.local
    • maximální délka je 64 znaků
    • je unikátní v rámci lesa a nepovinný
    • ukládá se do atributu userPrincipalName
Uživatelský účet a přihlašovací jméno

User Principal Name (UPN)

Protože věci okolo UPN nejsou úplně jednoduché, tak se na ně podíváme podrobněji.

Microsoft začal UPN používat pro doménové uživatele v době Windows 2000. Mělo se jednat o primární přihlašovací jméno, které by měl uživatel používat. Jeho forma je kratší než Distinguished Name a MS představa byla, že bude stejné jako emailová adresa (což v praxi může zjednodušit práci útočníkovi, který nemusí hádat jméno, ale pouze heslo), takže bude pro uživatele jednoduché pro pamatování. Oproti DN také není závislé na přesunu do jiného kontejneru ani přejmenování domény (přípona nemusí odpovídat doméně). Přesto bych řekl, že i v kombinaci Windows Server 2012 a Windows 8 se hojně využívá NetBIOS Logon Name.

Jako UPN přípona se defaultně nabízí DNS jméno aktuální a kořenové domény, ale můžeme přidat alternativní doménové jméno (v podstatě libovolný řetězec v DNS formátu), které vytvoří administrátor v rámci lesa. Správa se provádí pomocí Active Directory Domains and Trusts, kde klikneme pravým tlačítkem na stejně pojmenovanou položku a zvolíme Properties.

V souvislosti se sAMAccountName Microsoft doporučuje používat začátek UPN shodný. Ale protože je zde omezení na 20 znaků, tak v řadě případů se třeba v UPN používá jméno a příjmení, ale v sAMAccountName první písmeno jména a příjmení.

Microsoft v některých materiálech uvádí, že uživatelský účet má vždy sAMAccountName i User Principal Name. Jiné potvrzují to, co můžeme ověřit v praxi, že povinný je pouze atribut sAMAccountName a nikoliv userPrincipalName. Přesto je tu zajímavá informace, kterou jsem nalezl pouze v neoficiálních materiálech. A to, že UPN existuje vždy, i když není atribut userPrincipalName vyplněn. Někde mluví o defaultním UPN, někde o implicitním UPN, ale ve výsledku je to stejné (a možná ani nejde o UPN, ale prostě o jiný zápis sAMAccountName). Ať máme nebo nemáme vyplněné UPN, tak můžeme použít username@DnsDomainName, kde username je sAMAccountName a DnsDomainName je DNS jméno domény, kde se účet nachází. Pokud atribut userPrincipalName vyplníme, tak tím definujeme další explicitní UPN, kde můžeme použít libovolné uživatelské jméno a příponu (tu musíme zaregistrovat v rámci lesa).

Co je uživatelské jméno je hodně důležité pro Kerberos autentizaci. Kerberos užívá termín Client Name (Principal Name) a Realm, často narazíme i na použití User Principal Name. V AD doméně je Realm rovno DNS doméně a praktickými pokusy jsem ověřil, že Client Name je rovno sAMAccountName. Ve výsledku to odpovídá implicitnímu UPN.

Abych výše uvedené ověřil v praxi, tak jsem provedl následující testy. V doméněDNS jménem firma1.local a NetBIOS jménem firma1 jsem vytvořil UPN příponu pokus a uživatele s následujícími jmény:

distinguishedName CN=uzivatelsdlouhymjmenem,CN=Users,DC=firma1,DC=local
sAMAccountName    uzivatelsdlouhymjmen
cn                uzivatelsdlouhymjmenem
name              uzivatelsdlouhymjmenem
userPrincipalName uzivatelsdlouhymjmenem@pokus

Pak jsem se zkoušel přihlásit. Následující jména prošla:

  • FIRMA1\uzivatelsdlouhymjmen - NetBIOS logon name
  • uzivatelsdlouhymjmenem@pokus - zadané UPN
  • uzivatelsdlouhymjmen@firma1.local - implicitní UPN
  • firma1.local\uzivatelsdlouhymjmen - použití DNS jména domény v NetBIOS přihlášení

Přihlášení se nepodařilo:

  • FIRMA1\uzivatelsdlouhymjmenem
  • uzivatelsdlouhymjmenem@firma1.local
  • firma1.local\uzivatelsdlouhymjmenem

V popisu u MS jsem se o přihlašování dočetl následující. Když použijeme pro přihlášení sAMAccountName, tak zároveň určujeme doménu, v které se účet nachází (případně se použije aktuální). Při použití UPN není jasná doména (zadáváme pouze příponu, která nemusí odpovídat doméně), takže se nejprve hledá v aktuální doméně, pokud se UPN nenalezne, tak se použije globální katalog a hledá se doména, kde se účet nachází.

Při pokusech s různým přihlášením jsem také zachytával komunikaci. Aby bylo vše zajímavější, tak jsem se přihlašoval z jiné důvěryhodné domény (šlo o firma2.local). Když se klient snaží přihlásit, tedy získat TGT, tak v žádosti posílá přihlašovací údaje, které jsme zadali (viz. výše uvedené příklady). Pokud úspěšně získáme tiket, tak je v něm vždy DNS doména a uživatelské jméno sAMAccountName.

Pokud zadáme tvar doména\jméno, tak se hledá jméno (porovnává se s atributem sAMAccountName) v rámci domény doména (jedno jestli jde o NetBIOS nebo DNS). Tedy v KRG-AS-REQ paketu se použije Client Name = jméno, Realm = doména.

Pokud zadáme jméno@doména (tedy UPN), tak se nejprve hledá v lokální doméně, použije se Client Name = jméno@doména (porovnává se s atributem userPrincipalName), Realm = DNS jméno aktuální domény. Pokud se nenalezne, tak DC hledá pomocí globálního katalogu, jestli UPN existuje v jiné doméně nebo přípona odpovídá jiné doméně. Pokud ano, tak vrátí odkaz na doménu. Klient provede nový dotaz s jiným Realm a zaslaný na DC z odkazu.

Informace o uživateli na stanici

Na stanici můžeme použít určité řádkové příkazy, abychom získali informace o uživateli. První příkaz je dotaz na libovolného uživatele v doméně:

C:\>net user bouska /domain
The request will be processed at a domain controller for domain firma.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.

Druhá možnost je řada různých parametrů známého příkazu whoami, který zobrazí aktuálně přihlášeného uživatele.

C:\>whoami /upn
bouska@firma.local
C:\>whoami /fqdn
CN=Bouška Petr,OU=IS,OU=Firma,DC=firma,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=FIRMA.LOCAL
USERDOMAIN=FIRMA
USERNAME=bouska
USERPROFILE=C:\Users\bouska
windir=C:\WINDOWS

Service Principal Name (SPN)

Service Principal Name (SPN) se využívají v Active Directory, kde jsou uloženy v atributu servicePrincipalName u účtu. Jde o jeden ze základních prvků fungování Kerberos autentizace, spolu se službou DNS. SPN je unikátní identifikátor služby běžící na serveru. Jinak řečeno, je to jméno, pomocí kterého klient jednoznačně identifikuje instanci služby v rámci lesa. Každá služba, kde chceme využít Kerberos autentizaci, musí mít SPN registrované na účtu, který používá k přihlášení. Jedna služba může mít více rozdílných SPN, stejně tak k jednomu účtu může být přiřazeno více SPN.

SPN syntaxe je obecně ServiceClass/Host:Port/ServiceName, ale nejčastěji jde pouze o ServiceClass/Host. První část je název, který identifikuje obecně třídu služby, příkladem je ldap, GC, HOST, DNS, HTTP, TERMSRV, MSSQLSvc. Pro webové servery, ať jde o protokol HTTP nebo HTTPS, se používá HTTP. Druhá část je jméno počítače, kde služba běží. Většinou se používá FQDN (Fully Qualified Domain Name), ale pokud ke službě přistupujeme přes NetBIOS jméno, tak musíme použít to. Stejně tak v některých případech potřebujeme přidat DNS alias. Naštěstí SPN můžeme registrovat více. Příkladem SPN pro webový server je HTTP/www.firma.local.

Ve Windows (od Windows 7 / Server 2008) máme k dispozici nástroj pro příkazový řádek setspn, který slouží k prohlížení, nastavování a mazání SPN v Active Directory. Pro určité operace potřebujeme patřičné oprávnění. Můžeme tak ověřit existenci určitého SPN, či vyhledat všechna SPN pro danou službu či server. Několik příkladů hledání pomocí setspn:

setspn -Q HTTP/server.firma.local
setspn -Q HTTP/*    
setspn -Q */server.firma.local
setspn -Q */*

Pokud chceme hledat v rámci celého lesa, tak musíme přidat přepínač F.

setspn -F -Q HTTP/server.firma.local

Další příklad ukazuje registraci nového SPN pro webový server k účtu webserver.

setspn -S HTTP/www.firma.local firma\webserver

Odkazy

zobrazeno: 10308krát | Komentáře [0]

Autor:

Související články:

Kerberos protokol se zaměřením na SSO v AD DS

Nový seriál, který se podrobně věnuje protokolu Kerberos V5, hlavně v prostředí Microsoft Active Directory. Popíšeme si i řadu souvisejících věcí, které jsou potřeba pro pochopení fungování Kerberos Single Sign-On (SSO).

Active Directory a protokol LDAP

Správa počítačové sítě ala Microsoft, to je Active Directory. Jedná se o velice rozsáhlou skupinu technologií a služeb. Základem jsou adresářové služby, adresáře a komunikační protokol LDAP.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

Zatím tento záznam nikdo nekomentoval.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách