Archiwum kategorii: Security

Windows Terminal Services Logon „Access Denied”

Opublikowany przez
Odpowiedz

Dzisiaj przedstawię rozwiązanie problemu z Usługą Terminalową w środowisku z odrębnym serwerem Licencji Terminalowych.

Symptomy:

  • W trakcie logowania użytkownik otrzymuje komunikat „Access denied.”. Wyświetlany jest on zamiast ekranu logowania po uprzednim komunikacie „Welcome”.
  • W logu aplikacyjnym i systemowym nie występują żadne informacje o błędach, lub są one ewidentnie niezwiązane z podstawowym objawem.
  • W logu TerminalServices-LocalSessionManager występuje następujący wpis skorelowany z próbą logowania użytkownika: „Session X has been disconnected, reason code 12”, gdzie X oznacza numer sesji przydzielony konkretnej próbie logowania.
  • Problem ten dotyka zarówno systemy windows 2008 R2 jak i 2012 (R2).
  • Często towarzyszy tej sytuacji brak możliwości wymuszenia GPO

Tymczasowym rozwiązaniem problemu może być wykonanie dodatkowego wpisu w rejestrze:

1
2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\
IgnoreRegUserConfigErrors (DWORD) = 1

Po dodaniu tego wpisu konieczne jest ponowne uruchomienie komputera.

Po zażegnaniu kryzysu związanego z brakiem możliwości pracy użytkowników na spokojnie można przystąpić do diagnostyki, co się zepsuło tak naprawdę.
W tym konkretnym przypadku przyczyną był błędnie skonfigurowany Firewall na kontrolerach domeny przy użyciu GPO, gdzie był zabroniony ruch „SMB over TCP”.
Przyczyn należy w każdym razie szukać w otoczeniu kontrolerów domeny.

Generowanie Żądania certyfikatu z openssl dla Microsoft Enterprise CA

Opublikowany przez
2

Dawno temu pisałem o tym, jak wygenerować żądanie certyfikatu dla systemów nie będących Windowsami tak, aby dało się certyfikat wystawić na Microsoft Enterprise CA. Jako przykład podałem generowanie certyfikatów serwera vCenter
Niedawno temat powrócił, ale w nowej odsłonie, gdyż serwer vSphere wymaga zdefiniowania w certyfikacie odpowiednich Nazw Alternatywnych. Powstało pytanie, jak pogodzić te dwie funkcjonalności.
Okazuje się to być całkiem proste, trzeba tylko pamiętać, że choć plik konfiguracji openssl pozwala na wiele sekcji opisujących rozszerzenia żądania certyfikatu, to tylko jedna z nich może być wykorzystywana w trakcie generowania certyfikatu. Dlatego przygotowując plik konfiguracyjny dla określonego serwera warto uporządkować jego strukturę, względem propozycji przedstawionej w poprzednim wpisie.
Przykładowy plik konfiguracyjny może wyglądać następująco:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
openssl_conf = openssl_init

[ openssl_init ]
oid_section = new_oids

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ new_oids ]
MsCaCertificateTemplate = 1.3.6.1.4.1.311.20.2

[ v3_req ]
basicContraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server01, DNS:server01.domena.test
MsCaCertificateTemplate = ASN1:PRINTABLESTRING:VMwareCertificate

[ req_distinguished_name ]
countrName = PL
stateOrProvinceName = Malopolskie
localityName = Krakow
0.organizationName = Firma
organizationalUnitName = Oddzial
commonName = server01.domena.test

Analizując najważniejsze części:

  • Linia 1. Wskazuje na sekcję będącą konfiguracją globalną.
  • Linia 4. Wskazuje na sekcję defniującą OIDy. Linia ta jest jedyną w sekcji konfiguracji globalnej
  • Linia 13. Wskazuje na sekcję definiującą rozszerzenia, które zostaną dodane do żądania certyfikatu
  • Linia 15. Definiuje sekcję z OIDami.
  • Linia 16. Definiuje OID zarejestrowany i użytkowany przez Microsoft do oznaczania rozszerzenia definiującego szablon certyfikatu
  • Linia 22. Definiuje alternatywne nazwy serwera. Należy zwrócić uwagę na fakt, że w przykładzie używany jest prefiks DNS: Możliwe są także inne prefiksy.
  • Linia 23. Definiuje nazwę używanego szablonu certyfikatów. Należy zwrócić uwagę, że wykorzystywany jest wariant nazwy bez żadnych spacji. Nazywa się on „Certificate Template Name”, w przeciwieństwie do nazwy przyjaznej, nazywającej się „Certificate Template Display Name”

Pozostała cześć jest standardowa dla każdego żądania obsługiwanego przez openssl.

Eksport/Import szablonów certyfikatów z AD w Windows 2012

Opublikowany przez
4

Dzisiaj będzie parę słów o imporcie i eksporcie szablonów certyfikatów w Microsoft Active Directory.
Te dane są zapisane w partycji konfiguracji AD i przez to są współdzielone przez wszystkie domeny w obrębie lasu AD.
Czasem jednak zdarzają się sytuacje, kiedy zachodzi potrzeba przeniesienia tych danych między lasami, na przykład przy wdrażaniu testowanego uwcześnie rozwiązania w środowisku przed produkcyjnym do produkcyjnej domeny.
Zadanie takie może być wykonane na dwa różne sposoby. Pierwszy jest oczywisty dla tych, którzy mają z systemem windows duże doświadczenie, ale sposób ten jest brzydki i może powodować duże komplikacje w dzisiejszych systemach. Dlatego omówię go później.
Wraz z nadejściem systemu Windows 2008 R2 została wprowadzona nowa rola AD CS, która nazywa się AD CS Web Enrollment Service.
Służyć ona ma publikacji oraz użytkowaniu CA pomiędzy lasami AD, przy założeniu istnienia jedynie Zewnętrznej relacji zaufania pomiędzy tymi lasami. Więcej na ten temat można znaleźć tutaj.
Na tej samej stronie zostały też zamieszczone dwa świetne skrypty napisane w powershellu, które stanowią istotę dzisiejszego wpisu. Dzięki nim można wyeksportować oraz zaimportować szablony do oraz z plików XML w formacie MS-XCEP.
Niestety, te skrypty posiadają dwa błędy, które ujawniają się w trakcie pracy z systemem Windows 2012:

  1. skrypty zostały napisane jako zwykłe CMD-Let’y, które niestety nie są ładowane w W2k12. Szybkim obejściem tego problemu jest zakomentowanie deklaracji funkcji wraz z zamykającym nawiasem klamrowym na początku i końcu skryptu. Ponadto należy zakomentować deklarację parametrów jako cmd-let binding. Po tych zmianach skrypty uruchamiać się będą w normalny sposób z możliwością podania odpowiednich danych wejściowych, jak jest to wymagane.
  2. Funkcja eksportująca ma w niewłaściwy sposób zrealizowaną obsługę weryfikacji istnienia jednego z tablicowych atrybutów szablonu. Linię:
    1
    $superseded = if ($temp.Settings.SupersededTemplates -eq 0) {

    Należy zastąpić następującą:

    1
    $superseded = if ($temp.Settings.SupersededTemplates.Length -eq 0) {

    Dzięki temu zabiegowi zarówno eksport jak i import przebiegną pomyślnie..

  3. Ostatnią niedogodnością tych skryptów jest zależność od zewnętrznego modułu Power Shell. Ponieważ moduł jest napisany w .NET, na pewno istnieje możliwość wyeliminowania tej zależności, jednak ten temat będzie przedmiotem innego posta.

Wspominana wcześniej „brzydka metoda” to jest stara komenda ldifde wraz z wymaganymi flagami służącymi do eksportu:

1
ldifde -m -v -d cn=%Template1%,%LDAP% -f %Template1%.ldf

Najważniejszą częścią tej komendy jest przełącznik -m, który skutkuje wynikowym plikiem ldf pozbawionym odwołań do obiektów AD Forest.
Żeby zaimportować wygenerowany plik należy użyć bardzo podobnej komendy.:

1
 ldifde -i -k -f %Template1%.ldf

Metoda ta powinna działać dla wszystkich systemów, począwszy od Windows 2000.

Klonowanie tokena RSA? Nawet nie blisko…

Opublikowany przez
Odpowiedz

Przedwczoraj, na znanym blogu niebezpiecznik.pl został zamieszczony wpis z niepokojącą informacją

„Grupa kilku naukowców właśnie zademonstrowała sposób na `sklonowanie` tokena… „

Jako, że jednym z głównych moich zainteresowań jest kryptografia, z przyjemnością przeczytałem dokument przygotowany przez zespół w składzie Bardou, Focardi, Kawamoto, Simionato, Steel i Tsay.
Dokument ten przedstawia kilka usprawnień do znanego już od dawna (1998) ataku dokonanego przez D. Bleichenbacher’a pozwalającego uzyskać materiał wrażliwy poprzez serię wywołań standardowej funkcji API PKCS#11 C_UnwrapKey.
Pierwszą rzeczą, którą należy tutaj wyjaśnić, jest pojęcie Materiał Wrażliwy. Jest to informacja przenoszona poza tokenem w formie zaszyfrowanej. Najczęściej są to symetryczne klucze kryptograficzne (jak na przykład AES) służące do szybkiego szyfrowania dużych ilości danych (szyfrowanie symetryczne jest dużo szybsze od niesymetrycznego), ale także inne zaszyfrowane porcje danych.
Ponieważ dokument opisuje atak wykorzystujący wywołanie API mające w zamierzeniu zarządzać kluczami, często określenie Klucz jest używane jako Materiał Wrażliwy
Oryginalna metoda była na tyle wolna, że została nazwana „atakiem miliona pytań”, a sam atak został trochę zapomniany. Przytoczony na początku dokument spowodował burzę ze względu na zmniejszenie w bardzo pomysłowy sposób ilości wymaganych operacji na tokenie do wartości umożliwiających przeprowadzenie całego ataku w przeciągu godzin, czy nawet minut.
Jednak należy przypomnieć iż rozważana metoda ataku umożliwia na uzyskanie w formie jawnej jedynie danych podlegających szyfrowaniu kluczami RSA, nie zaś samych Kluczy RSA. Dlatego nie może być mowy o sklonowaniu tokena RSA!
Po tym zasadniczym wyjaśnieniu można przystąpić do analizy, jakie znaczenie praktyczne ma wynaleziona, nowa metoda.
Oceńmy fakty:

  1. Dostęp do funkcji C_UwrapKey możliwy jest tylko po otworzeniu sesji do tokena, czyli po podaniu hasła. Metoda ta korzysta z obiektu klucza prywatnego RSA i nie ma możliwości wywołania jej z kontekstu publicznego, a co za tym idzie bez wiedzy i zgody właściciela tokena.
  2. dane, które mogą wyciec muszą być wcześniej dostępne dla atakującego w formie zaszyfrowanej, co w praktyce jest trudne do realizacji.
  3. typowe zastosowania w biznesie tokenów RSA obejmują przede wszystkim autoryzację i podpis, tokeny wykorzystywane do szyfrowania jak i klucze przeznaczone do tego celu mają podwyższony poziom bezpieczeństwa (służą do tego odpowiednie atrybuty kluczy, stanowiące swoiste plany zastosowania, np. tylko do wymiany kluczy, czy tylko do szyfrowania danych użytkownika)
  4. Pomyślne przeprowadzenie ataku faktycznie umożliwia Wyprowadzenie poza system źródłowy kontroli nad danymi zaszyfrowanymi zaatakowanym kluczem symetrycznym.

Na podstawie powyższego można stwierdzić, że jeśli atak dojdzie do skutku, to tylko za autoryzacją użytkownika i tylko na danych, które są mało istotne z punktu widzenia bezpieczeństwa danych przechowywanych, gdyż Materiał Wrażliwy stanowiący Klucze Kryptografii symetrycznej jest zazwyczaj trudno dostępny nawet w formie zaszyfrowanej. Jako przykład weźmy system szyfrowania plików EFS, wykorzystywany w popularnym systemie plików NTFS, stworzonym przez Microsoft. Dostęp do zaszyfrowanych kluczy AES jest mocno ograniczony ze względu na dodatkowe zabezpieczenia tego systemu.

Czytaj dalej →

Błąd „The AD RMS installation could not determine the certificate hierarchy.” podczas reinstalacji AD RMS

Opublikowany przez
Odpowiedz

Istnieją rzadkie przypadki, kiedy zachodzi konieczność ponownej instalacji klastra RMS. Najczęstszą przyczyną takiej potrzeby jest nieudany proces provisioningu z jakichś prostych powodów, jak na przykład przypisany wcześniej certyfikat SSL do Web Site’a w IIS. Po nieudanym provisioningu należy odinstalować rolę AD RMS i po restarcie maszyny zainstalować ją na nowo. Niestety jednak nie zawsze dochodzi do pełnej deinstalacji usługi. Błąd cytowany w tytule ma opisanych kilka potencjalnych przyczyn i odpowiadających im rozwiązań. Jednak podstawowym problemem jest zawsze konfiguracja serwera w rejestrze. Należy jednak przed dokonaniem zmian w rejestrze upewnić się, że jest to dokładnie ta rzecz, którą chcemy osiągnąć.
Mianowicie omawiany błąd może wystąpić z następujących powodów:

  1. Nieprawidłowy Service Connectin Point – pojawia się w sytuacji, gdy z jakichś powodów w kontenerze CN=SCP, CN=RightManagementService, CN=Services, CN=Configuration, DC=domain, DC=lab pojawia się nieprawidłowy URL do usługi istniejącego już klastra RMSowego. Więcej informacji jedst dostępnych pod tym adresem. Jest to powód bezpośrednio podany w komunikacie błędu na zakończenie kreatora.
  2. Druga przyczyna jest wspominana we wpisie w logu aplikacji skojarzonym z niepowodzeniem provisioningu o numerze 204. Ta przyczyna pochodzi z błędu w rejestrze, ale zachodzi ona z powodu braku jednej wartości. Zgodnie z przytoczonym artykułem wystarczy ten klucz ponownie utworzyć.
  3. W przypadku odrzucenia poprzednich przyczyn należy zweryfikować zawartość gałęzi rejestru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS. W przypadku gdy występuje tam jakakolwiek wartość, a szczególnie taka, która zawiera odwołanie do nieistniejącego URL, może wystąpić omawiany błąd. Rozwiązaniem jest usunięcie wszystkich kluczy z tej gałęzi rejestru pozostawiając jedynie wartość (default).

W przypadku napotkania innej, nie opisanej tutaj przyczyny dla tego błędu bardzo proszę o pozostawienie komentarza.