Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Zakázat účet v AD neznamená, že to odpojí uživatele
duben 08
Zakázat účet v AD neznamená, že to odpojí uživatele

Zrovna tu řeším jeden problém s přístupem do Exchange mailboxu uživatelů, jejichž účty byly zakázány v Active Directory. Zdá se, že pokud účet v AD zakážete, tak se ještě velmi dlouho dostane do svého mailboxu přes ActiveSync a kratší dobu i přes OWA - viz ofiko článeček tady a tady. Jak si v článcích přečtete, je to způsobeno různě rozjetými spojeními, která není jednoduché ukončit. Články k tomu doporučují postup, co máte udělat, aby se doba zkrátila na minimum.

Překvapilo vás to?

Překvapit vás to nemělo

Tohle je normální. U všech aplikací. U všech systémů. Například i ISO 27002 na to pamatuje a nutí vás, abyste si přesně zdokumentovali u všech služeb, jak se zbavíte uživatele potom, co ho tam už nechcete. Nikdo nikdy neřekl, že se všechno hned odpojí samo, když zakážete účet v AD.

Důvody a příklady

Základní fakta. Pokud zakážete účet v Active Directory (disable), tak AD LDAP, Kerberos a NTLM a Schannel nadále odmítá tento účet ověřovat. To je naprosto v pořádku.

Jenže kdy probíhá ověřování? Ověřování probíhá obvykle vždy jen na začátku "session". Pod pojmem "session" se myslí buď Ctrl-Alt-Del lokální přihlášení na obrazovku nebo přes RDP, nebo pokud se ustavuje TCP spojení do nějaké vzdálené služby. Potom už nejspíš nikdy, dokud se "neohlásíte". Odhlásit chápu jako ukončení TCP spojení, nebo totální logoff z obrazovky (ne jen odpojení RDP session).

Příklad je místní přihlášení nebo přihlášení na RDP. Pokud se někam připojíte na RDP nebe přihlásíte lokálně, tak vám v paměti vznikne access token (už jsem o tom tady několikrát psal třeba tady a tady). S tímto access tokenem můžete na daném počítači provozovat procesy jak dlouho chcete, bez ohledu na to, jestli vám někdo zakázal účet. Dokonce pokud máte přímo na tom stejném RDP serveru například sdílený adresář, nebo SQL server, tak ho můžete používat až do aleluja, i když to je "jakoby" přes síť. K žádnému dalšímu ověřování nedochází.

Do sítě se už asi moc nedostanete, protože by to znamenalo nahodit nové TCP spojení a to by se muselo znovu ověřit? Jenže co když máte TCP spojení už navázána. Například máte ve wordu otevřený nějaký soubor ze sdíleného adresáře? Nebo máte spuštěného nějakého GUI SQL klienta a ten je připojený ke své databázi? Protože je TCP spojení navázáno od doby, kdy jste se ještě mohli ověřit, vydrží vám to opět až do smrti.

Stejný příklad je VPN. Zakážete účet, takže se člověk už znovu nepřipojí. Ale co když si tu VPN nahodil už dříve a má ji prostě pořád vytočenou? Žádné další ověřování obvykle neprobíhá.

Webový prohlížeč do nějaké webové aplikace je další příklad. Prohlížeče obvykle zavírají TCP spojení při nečinnosti cca 1 minuta. Web server IIS například kešuje access tokeny (pro Basic ověření) ještě 15 minut po tom, co vám zmizelo TCP spojení. Aby se ušetřila rychlost přihlašování a nemuselo se kvůli tomu chodit na DC. Dobrá, to skoro vypadá, že v prohlížečích to moc dlouho nevydrží.

Omyl, pokud vám ta webová aplikace do pohlížeče podstrčí nějaký "keep-alive" skript, který tu stránku jednou za 30 sekund třeba refreshuje, nebo alespoň nějakou její část, TCP spojení vám v pohodě vydrží, aniž byste si to vlastně uvědomovali.

Kerberos je další krásný příklad, dokonce s přístupem do sítě při vzniku TCP spojení. Ve výchozím stavu vám Kerberos vydává tikety na platnost 10 hodin. Jakmile máte TGT tiket, tak se po celou dobu jeho platnosti nekontroluje stav vašeho účtu. Takže scénář - přihlásím se a vydám si TGT, následně mě admin zakáže účet, ale já můžu ještě dalších 10 hodin chodit po síti kamkoliv. A to platí i pro totálně nově vznikající TCP spojení a dokonce nové generování TGS tiketů. O tom jsem tu taky už psal.

Co máte tedy dělat?

Musíte si zdokumentovat všechny "služby", které uživatelé mohou používat, tak jak vás k tomu vede ISO norma. Službou se rozumí počítač, mobil, RDP, VPN, WiFi, Exchange mailboxy, cokoliv. U každé služby si musíte také zdokumentovat, jak její uživatele "ukončíte", pokud je to potřeba.

Takže jaký je rozdíl mezi tím, jestli po zákazu účtu může člověk ještě hodně hodin stahovat poštu. Oproti tomu, že mu účet zakážete a on je ještě několik týdnů připojený na váš RDP terminal server a normálně si vykrádá data zákazníků z informačního systému?

Rozdíl je jenom v tom, že u toho OWA je to poněkud nečekané, že zavřete prohlížeč a přitom se tam znovu dostanete. Na druhé straně mám zkušenost, že i na ten Kerberos lidé obvykle zírají vcelku dost překvapeně.

Takže dojděte na můj kurz ISO 27001 a 27002 a třeba se dozvíte i další věci :-)

Comments

Re: Zakázat účet v AD neznamená, že to odpojí uživatele

To je jasnýýýý :)
Borek on 15.4.2016 17:09

Re: Zakázat účet v AD neznamená, že to odpojí uživatele

ondass on 25.4.2016 22:09

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments