Tajemnice certyfikatów cz.1
PKI to niszowa sztuka i mam wrazenie, ze jej wyznawcy to gatunek wymierajacy. Nie do konca rozumiem dlaczego - w koncu certyfikaty sa niemal wszedzie - SSTP, logowanie, karty inteligentne [co one potrafia, ze sa takie inteligentne?], publikacja uslug... czesto nawet nie zdajemy sobie sprawy z tego, ze uzywamy certyfikatu. Na dowód tego, ze PKI pozostaje sztuka tajemna jest fakt, ze w wiekszosci miejsc, które mialem okazje 'PKI' podejrzec, bylo to zle zrobione. W cudzyslowie, bo Root CA zainstalowany na kontrolerze domeny, na standardowych ustawieniach, wstyd nazywac 'PKI'.
Nie chcialem sie jednak rozwodzic nad ogólnym statusem PKI w firmach - w zamian kruczek dla wtajemniczonych.
Po przygotowaniu szablonów certyfikatów z opcja "publish to AD", certyfikaty sa przechowywane w AD... zaraz, zaraz. czy to oznacza, ze administrator domeny moze wziac którykolwiek certyfikat i przedstawic sie usludze jako ktos inny? Oczywiscie nie!
Jesli we wlasciwosciach obiektu uzytkownika zajrzymy do zakladki "Published Certificates" to owszem - certyfikaty tam sa, ale wylacznie czesci
publiczne. Czesc prywatna jest... prywatna! A wiec przechowywana lokalnie w profilu uzytkownika. W postaci pliku.
Aby wskrzesic certyfikat uzytkownika - np. komputer trafil... piorun - potrzebny jest Key Recovery Agent. A do KRA, potrzebna jest nietrywialna konfiguracja wymagajaca edycji szablonu, uprawnien i kilku innych operacji, co jest opisane tutaj.
A zatem zagadka:
Biorac pod uwage, ze klucz prywatny przechowywany jest w profilu, i nie ma zaimplementowanego Key Archival [zreszta nie ma to znaczenia], jak to sie dzieje, ze uzytkownik logujac sie do róznych stacji nadal ma swoje certyfikaty? Skad one sie biora?
Odpowiedzi sa dwie:
W jednym scenariuszu wcale ich nie ma. Uzytkownik loguje sie do nowej stacji i ma nowy certyfikat z autoenrollmentu. Brzydko. Jesli jakas usluga uwierzytelnia konkretnym certyfikatem to oczywiscie nie ma szansy zadzialac. Ale jest jeszcze druga opcja.
Opcja ta jest credential roaming. W duzym skrócie polega to na tym, iz certyfikaty sa przechowywane w bazie AD, w pliku NTDS.dit, i nie sa dostepne z interfejsu. Dla systemów Vista+ moga to byc nie tylko certyfikaty, ale równiez hasla. Opcje wlacza sie w GPO:
Dla chcacych sie dowiedziec szczególów dotyczacych tego mechanizmu zamieszczam kilka linków:
- Artykul Basi Wróbel, który w naszym ojczystym jezyku ogólnie przedstawia ten mechanizm
- W miare szczególowy opis algorytmu pokazujacy zdarzenia i dzialanie CR na stronach technet
- Duzo bardziej szczególowy opis pokazujacy gdzie dokladnie przechowywane sa informacje lokalne i jak caly mechanizm dziala na blogu Directory Services Team.
- Na tymze samym blogu – troubleshooting CR
eN.
Autor: nExoR
Comments
- Anonymous
January 01, 2003
warto pamietac, ze credential roaming moze spowodowac, ze wielkoc NTDS.dit urosnie i to bardzo bardzo :) na Vista+ istnieje opcja filtrowania co ma byc "chodzace za userem". na przyklad warto odfiltrowac certy smart card :) one chodza z uzytkownikiem fizycznie :) support.microsoft.com/.../2520487