Tajemnice certyfikatów cz.1

Tajemnice certyfikatów cz.1

  • Comments 1
  • Likes

PKI to niszowa sztuka i mam wrażenie, że jej wyznawcy to gatunek wymierający. Nie do końca rozumiem dlaczego - w końcu certyfikaty są niemal wszędzie - SSTP, logowanie, karty inteligentne [co one potrafią, że są takie inteligentne?], publikacja usług... często nawet nie zdajemy sobie sprawy z tego, że używamy certyfikatu. Na dowód tego, że PKI pozostaje sztuką tajemną jest fakt, że w większości miejsc, które miałem okazję 'PKI' podejrzeć, było to źle zrobione. W cudzysłowie, bo Root CA zainstalowany na kontrolerze domeny, na standardowych ustawieniach, wstyd nazywać 'PKI'.  

Nie chciałem się jednak rozwodzić nad ogólnym statusem PKI w firmach - w zamian kruczek dla wtajemniczonych.

Po przygotowaniu szablonów certyfikatów z opcją "publish to AD", certyfikaty są przechowywane w AD... zaraz, zaraz. czy to oznacza, że administrator domeny może wziąć którykolwiek certyfikat i przedstawić się usłudze jako ktoś inny? Oczywiście nie!

 

Jeśli we właściwościach obiektu użytkownika zajrzymy do zakładki "Published Certificates" to owszem - certyfikaty tam są, ale wyłącznie części
publiczne. Część prywatna jest... prywatna! A więc przechowywana lokalnie w profilu użytkownika. W postaci pliku.

Aby wskrzesić certyfikat użytkownika - np. komputer trafił... piorun - potrzebny jest Key Recovery Agent. A do KRA, potrzebna jest nietrywialna konfiguracja wymagająca edycji szablonu, uprawnień i kilku innych operacji, co jest opisane tutaj.

A zatem zagadka:

Biorąc pod uwagę, że klucz prywatny przechowywany jest w profilu, i nie ma zaimplementowanego Key Archival [zresztą nie ma to znaczenia], jak to się dzieje, że użytkownik logując się do różnych stacji nadal ma swoje certyfikaty? Skąd one się biorą?

Odpowiedzi są dwie:

W jednym scenariuszu wcale ich nie ma. Użytkownik loguje się do nowej stacji i ma nowy certyfikat z autoenrollmentu. Brzydko. Jeśli jakaś usługa uwierzytelnia konkretnym certyfikatem to oczywiście nie ma szansy zadziałać. Ale jest jeszcze druga opcja.

Opcją ta jest credential roaming. W dużym skrócie polega to na tym, iż certyfikaty są przechowywane w bazie AD, w pliku NTDS.dit, i nie są dostępne z interfejsu. Dla systemów Vista+ mogą to być nie tylko certyfikaty, ale również hasła. Opcje włącza się w GPO:

 

 Dla chcących się dowiedzieć szczegółów dotyczących tego mechanizmu zamieszczam kilka linków:

eN.

Autor: nExoR

Comments
  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment