Skip to Content

IT nieuczesane.
author

Author: ozz

AD FS – zmiana certyfikatu SSL

AD FS (Active Directory Federation Services) to usługa bezpiecznego udostępniania tożsamości poprzez jednorazowe logowanie (SSO), dzięki tej usłudze jesteśmy w stanie zalogować się do aplikacji zewnętrznych wykorzystując login/hasło konta z Active Directory.

W przypadku mojej konfiguracji są to dwa serwery działające w trybie farmy AD FS, dzięki nim użytkownicy domeny którą zarządzam są w stanie zalogować się wykorzystując swój login/hasło np. do Google Gmail lub Office 365. Nadmienię tylko, że w trybie farmy konfiguracja serwerów jest synchronizowana – zmiany wprowadzamy tylko na jednym, głównym serwerze, przy próbie ręcznego wprowadzenia zmian na drugim serwerze dostaniemy informację, że zmiany możliwie są do wprowadzenia tylko i wyłącznie na serwerze oznaczonym jako „Primary”

….

Jak dobrze wiecie certyfikaty wygasają ;-) , więc pewnie za jakiś czas każdy kto zajmuję się usługą Active Directory Federation Services stanie przed problemem zmiany certyfikatu SSL.

AD FS 2.2 (2012 R2) nie wymaga IIS, więc zmiana certyfikatu odbywa się trochę inaczej.

Byłem przekonany, że zmiana certyfikatu Service communication odpowiedzialnego za szyfrowanie wszystkich połączeń klientów wystarczy, okazało się,że nie. Przeglądarka twardo informowała, że korzysta ze starego certyfikatu…

Zmiana certyfikatu Service communication

AD FS Management -> Service -> Certificates -> Set Service Communication Certificate

Sam certyfikat, który wykorzystywany jest przez przeglądarkę zmienimy już tylko wykorzystując polecenia PS.

Do sprawdzenia czy został zmieniony:

Na koniec restart usługi AD FS, test w przeglądarce.

ozz.

Active Directory Fine-Grained Password and Account Lockout Policy

AD DS: Fine-Grained Password Policies, czyli możliwość tworzenia polis dotyczących haseł dla poszczególnych security groups lub użytkowników. Uwaga: nadpisują domyślne ustawienia z GPO ;-) .

Ostatnio stanąłem przed problemem kilku kont, w których nie mogłem pozwolić sobie na blokowanie po „x” próbach błędnego logowania. Oczywiście ustawienia dotyczące blokowania kont, złożoności haseł, długości haseł itd. miałem zdefiniowane w Default Domain Policy Pamiętałem, że od czasu wersji 2003 można ustawić w domyślnej polisie wszystkie ustawienia dotyczące hasła, ale… nakłada się to na wszystkich użytkowników. W takim razie jak ustawić inne wartości długości hasła, jego wygasania, czasu „lockout-u” itd.?

Co prawda do wersji 2012 R2 włącznie, nie zmieniło się, to że wszystkie ustawienia dotyczące haseł definiujemy w polisie domyślnej, natomiast od wersji 2008 wprowadzono Fine-Grained Password Policies. W bardzo prosty sposób czy to przy wykorzystaniu GUI czy też wszechobecnego PS jesteśmy w stanie ustawić inne ustawienia dla użytkowników lub całych wcześniej zdefiniowanych grup zabezpieczeń.

Dla przykładu zdefiniujmy polisę, która będzie miała dla jednej grupy zabezpieczeń ustawienia:

-długość minimum 8 znaków
-historię 6 haseł
-musi spełniać wymagania złożoności
-maksymalny wiek hasła 90 dni
-brak blokowania konta po nieudanych logowaniach

Na początek GUI (przykład na 2012 R2).

Otwieramy Active Directory Administrive Center, po lewej stronie rozwijamy naszą domenę -> System -> Password Settings Container

PPM -> New -> Password Settings

Otrzymamy okno jak poniżej:

1

Wypełnijmy poszczególne pola według wymagań, jakie wypisaliśmy powyżej. Dla wyjaśnienia Precedence, to priorytet. W sytuacji, kiedy mamy jedną polisę dla grupy X, drugą polisę dla użytkownika Y, który jest w grupie X, to na użytkownika Y nałożona zostanie polisa z niższą wartością Precedence.

2

Na koniec pozostaje wybranie grupy zabezpieczeń lub jednego/kilu użytkowników dla których ustawienia mają nadpisać „Default Domain Policy”. W sekcji „Directly Applies To” klikamy Add i wybieramy, dla kogo ma być aplikowana.

Ot cała filozofia. W celu sprawdzenia, na jakie konta nakłada się utworzona polisa należy skorzystać z polecenia w PowerShell Get-ADFineGrainedPasswordPolicy.

Utworzenie tej samej polisy przy wykorzystaniu PowerShell’a sprowadza się do wydania poniższego polecenia:

Następnie w celu dopisania kont lub grupy zabezpieczeń dla których ustawienia mają funkcjonować

Po więcej informacji odsyłam tutaj.

 

System Center Data Protection Manager 2012 R2 – VSS Failed, Replica inconsistent

Sytuacja prosta, System Center Data Protection Manager 2012 R2 robi backup dysków, udziałów, ale nie potrafi poradzić sobie ze zrobieniem Bare Metal Recovery oraz System State.

DPM error

Server Backup na maszynie, którą chcemy backupować wypisuje „VSS – Failed” i dalej: „there is not enough disk space to create the volume shadow copy on the storage location”. Jak to nie ma miejsca, jak na macierzy mam go od groma.

Na koniec jeszcze Event Viewer po stronie backupowanego klienta:

“The backup operation that started at ‚‎2014‎-‎08‎-‎25T13:22:49.633000000Z’ has failed because the Volume Shadow Copy Service operation to create a shadow copy of the volumes being backed up failed with following error code ‚0x80780119′. Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.”

Prawdopodobnie problem leży w partycji Recovery Point o pojemności 300MB. VSS potrzebuje przynajmniej 50MB wolnego miejsca. Jeżeli go nie ma Backup, nawet nie ruszy.

Wolne miejsce w prosty sposób sprawdzimy używając polecenia PowerShell’owego po stronie maszyny, którą chcemy backup’ować.

W wyniku, którego widzimy, że nasza partycja Recovery ma 300 MB, z czego tylko 29,99MB wolnego.

dpm_2

Upssss, niecałe 30MB to trochę za mało, do 50 kawałek brakuje…

Ponieważ problem leży w przestrzeni dyskowej po stronie klienta, rozwiązaniem będzie zwolnienie go, poprzez przeniesienie „shadowcopy storage” dla tego wolumenu („recovery partition volume”) na inny dysk.

Przy wykorzystaniu starego vssadmin pozostając w PS:

Zaznaczamy interesującą nas partycję Recovery (nie ma dopisanej żadnej litery)

Przyjmując, że korzystamy z PowerShell’a w wersji 3 zadziała poniższe polecenie(dzięki wykorzystaniu –% PS nie będzie analizował pozostałej linii kodu)  przy wersjach wcześniejszych możemy, żeby było najprościej użyć cmd.exe /c lub powalczyć ze znakami specjalnymi PowerShell (więcej info tutaj)

Wracamy na nasz serwer do konsoli System Center Data Protection Manager, prawym na Protection Group z naszym serwerem i  wykonujemy Perform consistency check…
Wszystko powinno wykonać się poprawnie.

Ozz.