Active Directory

Jak dodać do subskrypcji Azure kolejnego administratora z usługi Office365

Posted on Updated on

Jeśli mamy dostęp do subskrypcji Azure – w modelu pay-as-you-go, IUR, MSDN czy dowolnym innym, a następnie aktywujemy dla siebie usługi Office365 to może pojawić się pytanie – jak logować się do Azure za pomocą kont z Office 365, jak połaczyć elementy Office 365 z Azure.

Najprostszą drogą jest dodanie konta, które obecnie mamy w Office 365 do subskrypcji Azure jako co-administrator.

Poniższy scenariusz przedstawia jak dodać do subskrypcji osobę, która będzie współ-administratorem subskrypcji – nie regularnym użytkownikiem!

Opiszę poniżej jak to zrealizować:

  1. Logujemy się do naszej subskrypcji Azure i z lewej strony wybieramy zakładkę Azure Active Directory, jeśli zakładki nie widać to klikamy na dole w More Services i wyszukujemy ją na liście opcji.azure-add-office365-coadmin-01
  2. W Azure Active Directory otwieramy zakładkę Users and Groups, a w następnym oknie All Users. Następnie klikamy przycisk + Add. azure-add-office365-coadmin-02
  3. Wprowadzamy imię, nazwisko oraz adres e-mail użytkownika z Office365. Może to być adres e-mail jakim użytkownik loguje się do Office 365 – istotne jednak jest by adres był aktywny, tak by użytkownik mógł odebrać wiadomość.azure-add-office365-coadmin-03
  4. Następnie logujemy się do portalu Classic Azure (https://manage.windowsazure.com) i przechodzimy do sekcji Settings, ostatnia pozycja na dole.azure-add-office365-coadmin-10
  5. W ustawieniach wybieramy sekcję Administrators. Tu jest lista wszystkich kont, które posiadają uprawnienia administracyjne dla naszych subskrypcji. Możemy je później tutaj usuwać.azure-add-office365-coadmin-12
  6. Klikamy na dole przycisk ADD i w formularzu wprowadzamy adres e-mail użytkownika z Office 365. Zaznaczamy też poniżej do których subskrypcji użytkownik będzie mieć uprawnienia.azure-add-office365-coadmin-13
  7. W międzyczasie na skrzynkę użytkownika z Office 365 powinna dotrzeć wiadomośćpowinien dostać wiadomość e-mail z zaproszeniem do Azure Active Directory. Należy kliknąć na zielony przycisk Get Started.
    Tę operację proponuję wykonać w innej przeglądarce lub w sesji prywatnej tak by nie mieszać dwóch połaczeń do Azure w jednej sesji przeglądarki.
    azure-add-office365-coadmin-05
  8. Po kliknięciu pojawi nam się ekran powitalny – zaproszenie do zalogowania, aby powiązać konto Office 365 z Azure Active Directoryazure-add-office365-coadmin-06
  9. Logujemy się na nasze kontoazure-add-office365-coadmin-07
  10. Po poprawnym zalogowaniu trzeba będzie chwilkę odczekać, a następnie będziemy mogli się już zalogować do Azureazure-add-office365-coadmin-09

Azure AD Connect

Posted on Updated on

Azure - logo

Microsoft przygotował narzędzie, które ułatwia przyłączenie własnej domeny AD do Azure AD.
W chwili obecnej wersja beta umożliwia podłączenie pojedyńczego lasu AD, ale kolejne wersje będą umożliwiać łączenie domen wielokrotnych.
Cała operacja podłączenia składa się w zasadzie z kilku kroków; określenia poświadczeń, ustawień zasad połączenia, nazw domen oraz sposobu identyfikacji użytkowników.

Więcej szczegółów znajdziecie pod adresem: http://blogs.technet.com/b/ad/archive/2014/08/04/connecting-ad-and-azure-ad-only-4-clicks-with-azure-ad-connect.aspx

Aktualizacja certyfikatów dla AD FS 2.2

Posted on Updated on

Problem:

Po aktualizacji certyfikatów w roli AD FS 2.0 nie zmienia nam się certyfikat widoczny w przeglądarce, lub pojawiają się błedy: An error occurred while using SSL config for socket address 151.24.100.42:6331. The error status code is contained within the returned data.

Powód:

Aktualizacja certyfikatów SSL w usłudze AD FS 2.2 (Windows 2012 R2) nie aktualizuje certyfikatu przypisanego do usługi HTTP. AD FS 2.2 nie wymaga już roli IIS, więc wymiana certyfikatu dla usługi HTTP jest bardziej złożona.

Rozwiązanie:

    1. Musimy pobrać Hash dla certyfikatu, którego będziemy używać dla komunikacji HTTP – to może być ten certyfikat, który w konsoli AD FS nazywa się Service Communications.
      W tym celu z linii poleceń uruchamiamy komendę

      PS C:\Windows\system32> (Get-AdfsCertificate|Where-Object{$_.CertificateType -eq 'Service-Communications'}).Thumbprint

      W odpowiedzi dostaniemy ciąg znaków, np:

      E07B6F34A236966D6F00D399D6EC87DE55A84201
    2. Wyświetlamy listę certyfikatów przypisanych obecnie do usług HTTP
      netsh http show sslcert

      Polecenie zwróci nam taki wynik:

      SSL Certificate bindings:
       -------------------------
      
       Hostname:port : sts.contoso.com:443
       Certificate Hash : e08e6c34a53696bd6f00d399d6ec27de55a84207
       Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
       Certificate Store Name : MY
       Verify Client Certificate Revocation : Enabled
       Verify Revocation Using Cached Client Certificate Only : Disabled
       Usage Check : Enabled
       Revocation Freshness Time : 0
       URL Retrieval Timeout : 0
       Ctl Identifier : (null)
       Ctl Store Name : (null)
       DS Mapper Usage : Disabled
       Negotiate Client Certificate : Disabled
      
       Hostname:port : localhost:443
       Certificate Hash : e08e6c34a53696bd6f00d399d6ec27de55a84207
       Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
       Certificate Store Name : MY
       Verify Client Certificate Revocation : Enabled
       Verify Revocation Using Cached Client Certificate Only : Disabled
       Usage Check : Enabled
       Revocation Freshness Time : 0
       URL Retrieval Timeout : 0
       Ctl Identifier : (null)
       Ctl Store Name : (null)
       DS Mapper Usage : Disabled
       Negotiate Client Certificate : Disabled
      
       Hostname:port : sts.contoso.com:49443
       Certificate Hash : e08e6c34a53696bd6f00d399d6ec27de55a84207
       Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
       Certificate Store Name : MY
       Verify Client Certificate Revocation : Enabled
       Verify Revocation Using Cached Client Certificate Only : Disabled
       Usage Check : Enabled
       Revocation Freshness Time : 0
       URL Retrieval Timeout : 0
       Ctl Identifier : (null)
       Ctl Store Name : (null)
       DS Mapper Usage : Disabled
       Negotiate Client Certificate : Disabled

      Interesujące nas pozycje to:
      Hostname:port – adres do jakiego przypisany jest certyfikat, będzie nam to później potrzebne
      Certificate Hash – hash obecnego certyfikatu (inny niż ten który zwróciło nam polecenie Get-ADFSCerficate)
      Application ID – UID aplikacji, która usługę HTTP wystawia – również potrzebny później

    3. Usuwamy złe wpisy
      :netsh http delete sslcert hostnameport:sts.contoso:443
      netsh http delete sslcert hostnameport:localhost:443
      netsh http delete sslcert hostnameport:sts.contoso:49443
      

      Oczywiście w pole hostnameport podajemy właściwe wartości

    4. Dodajemy nowy certyfikat do usług, pamiętając by podać poprawne wartości HostnamePort, CertHash oraz AppID.
      netsh http add sslcert hostnameport="sts.contoso.com:443" certhash="E07B6F34A236966D6F00D399D6EC87DE55A84201" appid="{5D89A20C-BEAB-4389-9447-324788EB944A}" certstorename=MY
      netsh http add sslcert hostnameport="localhost:443" certhash="E07B6F34A236966D6F00D399D6EC87DE55A84201" appid="{5D89A20C-BEAB-4389-9447-324788EB944A}" certstorename=MY
      netsh http add sslcert hostnameport="sts.contoso.com:49443" certhash="E07B6F34A236966D6F00D399D6EC87DE55A84201" appid="{5D89A20C-BEAB-4389-9447-324788EB944A}" certstorename=MY

i gotowe.

Samba 4.0 i serwer Active Directory na Linux

Posted on

Temat nie jest specjalnie świeży, ale też nie jest o nim specjalnie głośno. Nowa wersja Samba 4.0 pozwala na uruchomienie na serwerze Linux pełnoprawnego kontrolera AD, wraz z GPO, DNS itp. Do tak przygotowanego AD można podłączyć stacje robocze, można też podłączyć inne kontrolery AD – choćby te oparte o Windows Server.

Postaram się w tym tygodniu uruchomić testowe laboratorium w którym za pomocą takiego AD uruchomię klaster failover na Hyper-V Server, wtedy też podzielę się wrażeniami.

Klonowanie kontrolerów Active Directory w Windows Server 2012

Posted on Updated on

Jak można wykonać klona kontrolera domeny wykorzystując Windows Server 2012.

  1. Operację można przeprowadzić tylko na wirtualizatorze, który wspiera funkcjonalność VM-Generation-ID – m.in. Hyper-V 3.0
  2. Autoryzuj oryginalny źródłowy kontroler AD poprzez dodanie tego kontrolera do grupy Cloneable Domain Controllers w Active Directory.
  3. Potwierdź czy źródłowy kontroler można sklonować, poprzez polecenie PowerShell
    Get-ADDCCloningExcludedApplicationList
  4. Sprawdź czy lista zainstalowanych aplikacji będzie działać poprawnie jeśli zostanie zmieniona nazwa komputera lub jego SID. Musisz usunąć niekompatybilne oprogramowanie z źródłowego kontrolera DC zanim przeprowadzisz dalsze operacje.Dla pozostałego oprogramowania jeśli jest kompatybilne z procesem klonowania – zaktualizuj listę kompatybilności:
    Get-ADDCCloningExcludedApplicationList –GenerateXML
  5. Skonfiguruj oryginalny kontroler z instrukcjami do konfiguracji klona DC poprzez poniższe polecenie PowerShell. Utworzy ono plik o nazwie DCCloneConfig.xml w katalogu NTDC DIT (domyślnie C:\Windows\NTDS). Przykładowy plik jest dostępny pod adresem C:\Windows\System32\SampleDCCloneConfig.xml
    New-ADDCCloneConfigFile
    -CloneComputerName "Nazwa_nowego_DC" \
    -SiteName "Nazwa_Site_AD" \
    -Static -IPv4Address "Adres_IP_nowego_DC" \
    -IPv4SubnetMask "Maska_podsieci_nowego_DC" \
    -IPv4DefaultGateway "Adres_gateway_nowego_DC" \
    -IPv4DNSResolver "Adres_IP_serwera_DNS" \
    -PreferredWINSServer "Adres_IP_serwera_WINS"
  6. Wyłącz maszynę wirtualną z oryginalnym kontrolerem by przygotować się do klonowania.
    Stop-VM –Name "Nazwa_serwera_DC" –ComputerName "Nazwa_serwera_HyperV"
  7. Wykonaj export maszyny do nowego folderu (w przypadku Windows 2012 R2 można to zrobić bez wyłączania serwera)
    Export-VM –Name "Nazwa_serwera_DC" –ComputerName "Nazwa_serwera_HyperV" –Path "Sciezka_do_katalogu_z_miejscem_na_nowy_DC"
  8. Zaimportuj maszynę wybierając opcję Copy the virtual machine (create a new unique ID). Jeśli operację wykonujemy na tym samym hoście Hyper-V to należy edytować plik konfiguracji maszyny, znajduje się on w podkatalogu Virtual Machines w katalogu do którego exportowaliśmy maszynę. Plik ma postać GUID.xml (gdzie GUID to obecny GUID maszyny). Edytujemy wpis na pozycji:
    configuration / properties / name

    Szukamy ciągu: <name type=”string”>Nazwa_Starego_DC</name>

    Oraz koniecznie zmieniamy ścieżkę dla lokalizacji plików VHD, Snapshotów, Smartpagging oraz konfiguracji maszyny, w przeciwnym wypadku nadpiszemy oryginalny serwer DC.

    $vm = Import-VM –Path "Sciezka_z_exportem_maszyny_DC2" \
    –Copy –GenerateNewId \
    –VHDDestinationPath "Katalog_dla_noweg_DC\Virtual Hard Disks" \
    –SnapshotFilePath "Katalog_dla_noweg_DC" \
    –SmartPagingFilePath "Katalog_dla_noweg_DC" \
    –VirtualMachinePath "Katalog_dla_noweg_DC"
  9. Włącz kontroler źródłowy (jeśli go wyłączałeś) i nowo utworzony kontroler DC. Częścią procesu startu będzie to iż nowo utworzony kontroler DC wykona instrukcje jakie ma w pliku DCCloneConfig.xml by ustawić konfigurację sieci, nazwę komputera itp.

Opracowane na podstawie: http://blogs.technet.com/b/keithmayer/archive/2012/08/06/safely-cloning-an-active-directory-domain-controller-with-windows-server-2012-step-by-step-ws2012-hyperv-itpro-vmware.aspx