Quantcast
Channel: TechNet Blogs
Viewing all articles
Browse latest Browse all 36188

tajemnice certyfikatów cz.2 - przypisanie klienta do konkretnego CA

$
0
0

takie pytanie na rozgrzewkę: jeśli jest kilka issuing CA w domenie, skąd klient wie do którego się zgłosić?

podobne, ale trochę trudniejsze: jak zmusić klienta do skorzystania z konkretnego CA?

scenariusz: duża korporacja, która posiada wiele oddziałów na całym świecie. projekt PKI zakłada, żeby użytkownicy dostawali certyfikaty z autoenrollmentu. lokalizacje połączone są ze sobą różnymi łączami. chcemy zaprojektować strukturę tak, aby użytkownicy z danej lokalizacji geograficznej dostawali certy z CA 'gdzieś w pobliżu'. zdefiniowanie CA w Azji i powiedzenie że 'to w pobliżu' może brzmieć trochę śmiesznie (; ale załóżmy że podział na kontynenty wystarczy.

najpierw więc trzeba odpowiedzieć na pytanie pierwsze - jak klient wybiera CA? po pierwsze w GPO definiuje się właściwości enrollmentu... w zasadzie to się go po prostu włącza. klient sprawdza w AD [zakładam scenariusz z pełną integracją z AD] szablony a następnie szuka CA, które dany szablon obsługuje. AFAIK - jest to losowy algorytm i jeśli jeden serwer jest niedostępny, skorzysta z innego.

czas więc na więcej szczegółów, które dadzą odpowiedź na drugie pytanie. układankę trzeba złożyć z kilku elementów:

  1. na każdym CA publikuje się szablony, które wydaje - np. jeden CA może wydawać certyfikaty NAP a inny dla użytkowników
  2. szablony mają zdefiniowane uprawnienia. m.in. jest tam uprawnienie 'autoenroll'
  3. uprawnienia przypisuje się grupom w AD

finalnie więc należy:

  • założyć grupy dla regionów - np. 'ASIA', 'EU', 'S_AMERICA' itd.
  • utworzyć szablony dla użytkowników i komputerów dla każdego regionu - np. 'ASIA Users', 'EU Users'... szablony mogą być niemal identyczne - poza nazwą i uprawnieniami
  • należy dla szablonów zdefiniować adekwatne uprawnienia 'autoenroll' dla grup regionalnych
  • należy utworzyć issuing CA dla regionu i opublikować na nim konkretny szablon.

jest też drugi sposób, który jednak uważam za 'brudny'. 'brudny' bo przypomina raczej workaround niż rozwiązanie i posiłkuje się mechanizmem z zupełnie innej warstwy - sieciowej a nie aplikacyjnej. no i ma swoje skutki uboczne, które mogą mieć trudne do przewidzenia konsekwencje:

  • ponieważ klienci poszukują pierwszego CA jaki odpowie, publikującego dany szablon... wystarczy pomiędzy lokalizacjami blokować ruch sieciowy do pozostałych CA.

eN.

 

autor: nExoR


Viewing all articles
Browse latest Browse all 36188

Trending Articles