Pokud se podíváte na svůj access token (například pomocí WHOAMI /ALL), možná v něm objevíte skupinu NT Authority\This Organization. Lépe řečeno je to jen SID, není to ve skutečnosti skupina, protože to nemá nikde explicitně definované členství.
Vždycky jsem si myslel, že to souvisí s nějakými trusty, ale nevěděl jsem přesně jak. Zkoumal jsem to tedy před nedávnem, co to je přesně zač, a zjistil jsem, že k tomu je jen velice sporadická dokumentace. Tak jsem musel provést průzkum bojem. A tu je výsledek.
Trust a selective authentication
Souvisí to s forest trustem (vztahem důvěry) a jeho selective authentication. Tedy přesně, jen v případě, že máte na trustu zapnutu selective authentication. Tu můžete mít až od forest functional level (DFL, úroveň funkčnosti domény) na úrovni Windows 2003.
Takže řadiče domény (DC) od verze DFL 2003 dávají do každého Kerberos TGT tiketu (upřesnění úplně dole) (a nebo NTLM autentikátoru) tento SID. Tedy přesně se jedná o:
NT AUTHORITY\This Organization
S-S-1-5-15
Dávají to tam všem uživatelům ze stejného forestu. Pokud máte nějaký external trust, nebo forest trust, ale bez selective authentication, tak to tam máte taky. Takže samotný fakt, že jste se ověřili přes trust, tohle neovlivňuje.
Až v okamžiku, kdy je ten trust selektivní (tedy má zapnutu funkci selective authentication), tak se to může v Kerberos ticketu objevit. Potom je v tiketech uživatelů z jiných forestů jiný SID:
NT AUTHORITY\Other Organization
S-S-1-5-1000
Na co to tam je? No tak můžete si podle toho poznat, kdo je tu přes selektivní trust. Ale to je divné, ne? Proč by mě zajímalo, jestli je tu přes selektivní trust, zatímco u normálního trustu to vůbec poznat nejde?
Vydávání TGS pro služby
No uživatel je přece identifikován svým TGT. Když chce jít na nějakou službu, potřebuje k tomu TGS. Servisní tiket TGS se vydává jen na základě již dříve vydaného TGT.
Jak by DC poznalo, že to TGT přišlo přes selektivní trust? Pokud je to TGT ze selektivního trustu, tak se před vydáním TGS musí provést kontrola na oprávnění Allowed to Authenticate na účtu služby.
No a DC to pozná prostě a jendoduše podle toho, že v TGT tiketu je vložen tento NT AUTHORITY\Other Organization SID. Když tam je, musí se před vydáním TGS dělat kontrola oprávnění Allowed to Authenticate. Pokud tam není, prostě se vydá TGS bez keců.
Podle mě to je parádní věc :-)
Proč to není potřeba u externích selektivních trustů?
Externí trusty (external trust) jsou vždycky NTLM. To znamená, že každé ověření, do libovolné služby, musí vždy procházet skrze všechna DC po trustových linkách. Tím pádem se selective trust zjistí při každém ověřování. Zatímco v TGT to musí být poznamenáno.
Co přesně znamená, že ten SID je uvnitř TGT?
No, on ve skutečnosti nemůže přímo být uvnitř TGT. TGT vydává account doména. Ta vůbec nemá ponětí kam, nebo ze kterého počítače a ze které domény, se ten uživatel hlásí. Prostě jenom tak vydá TGT.
Takže v tom originálním TGT tyhle SIDy nebudou. Tedy asi tam je vždycky NT AUTHORITY\This Organization typuju.
Až když chce člověk na službu do cizí domény, musí si nejprve vydat jakési "trustové TGT". To vydává právě řadič z cílové resource domény. Teprve potom můžu dostat na základě tohoto "trustového TGT" cílové TGS.
Takže když jdu na službu v trusting doméně, mám vlastně svoje TGT od account domény, trustové TGT od trusting domény a TGS pro službu od trusting domény.
No a právě při vydávání toho trustového TGT je poznat, jestli je to selective trust. A když je, tak do toho trustového TGT dostanu NT AUTHORITY\Other Organization namísto původního NT AUTHORITY\This Organization.
A při žádosti o jakýkoliv další TGS tiket se prostě zkontroluje, jestli je na cílovém účtu povoleno Allowed to Authenticate.
Já to úplně žeru, jak to všechno dává smysl :-)