Zmiany w Azure AD Connect

Ponad rok w aplikacji Azure AD Connect nie widać było żadnych aktualizacji, ale ostatnie miesiące przyniosły istotne zmiany, na które warto zwrócić uwagę i zaaplikować jak najszybciej, zwłaszcza w konktekście znalezionych podatności oraz wygasającego wsparcia dla poszczególnych komponentów.

Wchodząc na stronę historii wersji Azure AD Connect, zobaczymy, że dostępne są dwie ścieżki:

• Azure AD Connect 2.0, do instalacji na serwerze w wersji Windows Server 2016 lub nowszej,
• Azure AD Connect 1.6, do instalacji na starszych wersjach systemu (które już wyszły ze wsparcia lub za chwilę wyjdą)

Co nowego przynosi wersja 2.0? Jest kilka istotnych zmian, w komponentach, które wykorzystuje nowa wersja (więcej informacji w dokumentacji produktu):

• lokalna baza danych w wersji SQL Server 2019 LocalDB. Instalowany w wersji 1.x SQL Server 2012 wychodzi ze wsparcia w lipcu 2022.
• biblioteka uwierzytelnienia MSAL zamiast ADAL, która będzie wycofana w czerwcu 2022,
• TLS 1.2 jako domyślny i jedyny protokół zabezpieczania transmisji (TLS 1.0 i 1.1 są od dluższego czasu oznaczane jako podatne na ataki) - przed aktualizacją musimy ustawić obsługę protokołu TLS w odpowiedniej wersji,
• Visual C++ Redist 14 jako komponent niezbędny dla SQL 2019

Jak możemy zrobić upgrade? Oczywiście jest możliwy upgrade in-place, jeżeli oczywiście mamy serwer w co najmniej wersji 2016, po zakończeniu aktualizacji musimy pamiętać jednak o odinstalowaniu komponentów SQL 2012. Niestety auto-upgrade nie zadziała, musimy pobrać najnowszą wersję produktu i uruchomić proces instalacji samemu.

Po zweryfikowaniu konfiguracji serwera i instalacji dodatkowych składników, kreator poprosi nas o wprowadzenie poświadczeń administratorskich i przejdzie do kroku finalnego (kolejny rysunek).

Możemy również wykorzystać ścieżkę eksportu i importu konfiguracji, kiedy na przykład musimy zmienić wersję systemu operacyjnego. Proces jest dobrze opisany w dokumentacji.

Konferencja K@SSK i Majowe Mrozy - warsztat Azure AD

 Wczoraj miałem przyjemność prowadzić warsztat dla szkolnych administratorów Office 365 na temat "Azure AD – konfiguracja zabezpieczeń i monitorowanie użytkowników". Warsztat był częścią konferencji K@SSK & Majowe Mrozy, dotyczącej nowoczesnej edukacji, a przeznaczonej dla nauczycieli i pracowników szkolnictwa. Ostatni rok dosyć gwałtownie zmienił nasze spojrzenie na narzędzia chmurowe i korzystanie z platform takich jak Microsoft 365, ważna jednak świadomość, jak robić to w sposób bezpieczny, szczególnie, gdy jesteśmy odpowiedzialni za administrowanie takim środowiskiem.

Godzina to mało czasu, żeby przekazać tyle wiedzy ile bym chciał, dlatego też chciałem nieco rozwinąć informacje, na temat zabezpieczania i weryfikacji środowiska Office 365, które chciałem przekazać przy okazji tych warsztatów. Microsoft niestety w planie EDU A1 włącza tylko niewielką część komponentów umożliwiających zabezpieczenie środowiska Microsoft 365 i Azure AD, nie oznacza to jednak że nie można zrealizować podstawowych zaleceń. Postaram się zatem przypomnieć elementy najważniejsze wg. Microsoft i mnie, które nawet przy ograniczonych możliwościach, ułatwiają pracę administratorów:

Po pierwsze - uwierzytelnianie wieloskładnikowe (MFA) jest potrzebne, przynajmniej dla administratorów. Już ponad rok Microsoft dla nowych organizacji chmurowych włącza tzw. Domyślne wartości zabezpieczeń (Security Defaults), czyli wymuszanie zabezpieczania logowania do chmury poprzez dodatkowy składnik, powiązany z telefonem komórkowym - konieczność dodatkowego zabezpieczenia logowania poprzez kod przesyłany SMS lub użycie aplikacji Microsoft Authenticator zainstalowanej na telefonie.

Ustawienie możemy zmienić, poprzez panel administracyjny Azure AD, wchodząc we właściwości naszej organizacji. Zdecydowania większość placówek oświatowych wyłącza to ustawienie i o ile rozumiem takie podejście w stosunku do uczniów, to przynajmniej szkolni administratorzy i osoby z delegowanymi dodatkowymi uprawnieniami powinni mieć takie zabezpieczenie włączone.

Konfiguracja jest naprawdę bardzo prosta, chociaż nie zawsze oczywista. Jak skonfigurować sobie MFA? Każdy użytkownik usługi Office 365 ma swoją stronę profilową My Account, na której może wskazać metody związane z zabezpieczaniem dostępu i samodzielnym resetowaniem hasła (Informacje zabezpieczające).

Powinniśmy tam zapisać nasz numer telefonu i prywatny adres mailowy, do celów awaryjnych. Możemy również dodać weryfikację konta właśnie poprzez aplikację Authenticator.

Po drugie - korzystając na co dzień z panelu administracyjnego Microsoft 365 - https://admin.microsoft.com, warto do ekranu startowego dodać kafelki komponentów, z których często korzystamy, lub które szybko pokażą nam problemy ze środowiskiem.

Po trzecie - Warto korzystać z panelu administratora Azure AD, gdzie możemy sprawdzić np. kiedy użytkownik logował się po raz ostatni i z jakiego adresu IP, kiedy i przez kogo został usunięty zespół w Teams, oraz znaleźć wiele innych informacji na temat aktywności użytkowników. Niestety portal Azure AD pokazuje logi z ostatnich siedmiu dni. Jeżeli chcielibyśmy mieć dłuższą historię logowań, to możemy utworzyć bezpłatną subskrypcję Azure i wypróbować takie usługi jak Log Analitics czy Azure Sentinel.

Można wyliczać jeszcze długo, ale zachęcam do poznawania Microsoft 365 i Azure AD, po to by odkrywać kolejne możliwości i lepiej zarządzać swoim środowiskiem.

Teams - Współpraca z użytkownikami zewnętrznymi

 Jednym z tematów, który często pojawia się w pytaniach dotyczących Microsoft Teams jest dołączanie do spotkań lub do zespołów osób spoza naszej organizacji Office 365. Żeby omówić ten temat, najpierw musimy wiedzieć, jakie typy użytkowników mamy do dyspozycji i jakie są ich uprawnienia/możliwości pracy w Teams naszej organizacji/szkoły. Tak więc mamy 3 typy użytkowników zewnętrznych:

• Użytkownik sfederowany - użytkownik z innej organizacji Microsoft Teams - jeżeli nasza organizacja ma włączoną federację (współpracę) z innymi organizacjami Teams, to możemy połączyć się bezpośrednio z takim użytkownikiem, zarówno głosowo jak i poprzez chat. Jeżeli federacja jest typu natywnego (obie organizacje pracują w trybie Teams Only), to również możemy zobaczyć status dostępności takiej osoby. Użytkownik tego typu nie ma dostępu do naszych zespołów, ale może być zapraszany na spotkania.
• Użytkownik anonimowy - można zapraszać taką osobę na spotkania/lekcje, wysyłając zaproszenie mailem na adres pocztowy danej osoby. W zależności od zdefiniowanych polityk spotkań użytkownik anonimowy może tylko uczestniczyć w spotkaniu, ale może również być prezenterem. Administrator może również zablokować możliwość dołączania użytkowników anonimowych.
• Gość - Użytkownik z innej organizacji Teams, Skype for Business, a nawet z innej platformy jak np. Google. Goście mogą należeć do zespołów Teams, mieć dostęp do witryn Sharepoint oraz wybranych aplikacji. W zależności od ustawień na poziomie administracyjnym możemy pozwolić wszystkim pracownikom zapraszać gości do swoich zespołów Teams, możemy to również ograniczyć, pozwalając tylko administratorom dodawać gości na poziomie organizacji, a do zespołów Teams dodawać tylko wcześniej utworzone konta gości.

Jak widać, w zależności od potrzeb, możemy skorzystać do różnych celów z różnego typu kont zewnętrznych, jednak właściciel zespołu, a nawet część administratorów nie zawsze wie, jak zmienić ustawienia w zakresie ograniczeń pracy gości czy użytkowników anonimowych. Gdzie szukać rozwiązania naszych problemów?

W przypadku użytkowników anonimowych, zablokowanie dostępu do spotkań jest proste - wystarczy w ustawieniach spotkań (konsola administracyjna Teams), wyłączyć dostęp anonimowy - jak widać na poniższym rysunku.

Zezwolenie na udział użytkowników globalnych jest ustawieniem globalnym, co może ograniczać możliwość zapraszanie użytkowników zewnętrznych zarówno uczniom jak i nauczycielom - zaproszenie na spotkanie wyślemy, ale użytkownik niezalogowany do Teams nie dołączy do spotkania. Jednak w przypadku, gdy mamy włączoną federację, a zaproszona osoba ma konto w innej organizacji Teams, to będzie mogła dołączyć do spotkania jako użytkownik sfederowany. Żeby ograniczyć również tą możliwość musimy na poziomie organizacji ograniczyć federację z innymi organizacjami. Domyślnie w ustawieniach organizacji Teams współpraca federacyjna z innymi organizacjami Teams i Skype for Business oraz Skypem konsumenckim jest włączona (rysunek poniżej).

Jeżeli chcemy ograniczyć współpracę z innymi organizacjami, możemy po prostu dodać domenę zaufanej organizacji, a nawet wyłączyć całkowicie współpracę federacyjną.

Jednak najwięcej możliwości współpracy daje nam konto gościa - tylko ten typ użytkownika zewnętrznego może być dodany do zespołu i np. wspólnie współpracować edytując dokumenty projektowe udostępnione w danym zespole. Domyślnie wszyscy mogą dodawać gości na poziomie zespołu (kolejny rysunek).

Jednak ze względów bezpieczeństwa dobrze jest ograniczyć możliwość dodawania gości, tak, żeby tylko administratorzy organizacji mogli dodawać nowe konta. Należy to zrobić z konsoli Azure Active Directory->Użytkownicy->Ustawienia Użytkownika->Zarządzaj ustawieniami współpracy zewnętrznej.

Dobrze jest również rozważyć jakie możliwości powinni mieć goście w zespole. Właściciel zespołu może zablokować lub zezwolić gościom na tworzenie i kasowanie kanałów (kolejny rysunek), administrator może również ograniczyć opcje gościa (ustawienia globalne organizacji Teams w panelu administracyjnym Teams) dotyczące prowadzenia rozmów, konwersacji i udziału w spotkaniach (ostatni rysunek).

Global Azure Boot Camp 2019

Idą Święta a po Świętach nadciąga Global Azure Boot Camp. Już 27 kwietnia w kilku polskich miastach również odbędą się eventy z tego cyklu - między innymi w Warszawie, Łodzi i Poznaniu. Ja serdecznie zapraszam na spotkanie w Poznaniu, gdzie będę opowiadać o hybrydowym uwierzytelnieniu w usługach chmurowych. Rejestrować można się tutaj.

bramki antyspamowe i LDAPS

Niedawno miałem ciekawy przypadek przy konfiguracji bramki Symantec Messaging Gateway. Dla lepszej ochrony systemu pocztowego (jak dla mnie oczywiście Exchange), bramki te, podobnie jak wiele innych tego typu rozwiązań, pobierają z katalogu LDAP listę adresową organizacji. W ten sposób mogą weryfikować listę odbiorców dla poczty przychodzącej i listę nadawców dla poczty wychodzącej. W ten sposób również użytkownicy Exchange mogą łączyć się do swojej kwarantanny, znajdującej się na bramce. Konfiguracja integracji bramki antyspamowej z Active Directory jest stosunkowo prosta i polega na wskazaniu serwera, DN konta używanego do czytania danych (w przypadku AD może być również UPN tego konta), no i oczywiście hasła tego konta. Dodatkowym atrybutem połączenia jest port TCP (domyślnie 389). Kolejnym krokiem jest test połączenia.

Przy próbie połączenia kreator pokazywał mi błąd, świadczący o nieprawidłowym koncie. Jednak próba połączenia z AD z komputera domenowego działała poprawnie. Po weryfikacji haseł, ustawień firewalla i innych kwestii sieciowych, sprawdziłem polisy GPO. Okazało się, że zarówno na kontrolerach domenowych, jak i na stacjach roboczych jest ustawione wymuszenie podpisywania pakietów LDAP (LDAP signing). Niestety funkcja ta powoduje problemy z uwierzytelnieniem z urządzeń takich jak SMG czy SonicWall.

Alternatywą było ustawienie połączenia na LDAPS. Przełączyłem port na 636 (domyślny port połączenia LDAPS) i tym razem dostałem komunikat, że nie mogę nawiązać połączenia z serwerem. O co chodzi? Człowiek przyzwyczaił się, że w środowisku domenowym wdrażany jest do wewnętrznych celów organizacji urząd certyfikacyjny (CA), a że całkiem sporo firm instaluje CA na kontrolerze domeny, a w takim wypadku dla kontrolerów domyślnie instalowane są certyfikaty, właśnie służące do szyfrowania komunikacji LDAP (czyli właśnie LDAPS). Jeżeli jednak w AD nie ma zainstalowanego urzędu certyfikacji, to takich certyfikatów niestety nie ma domyślnie zainstalowanych, więc LDAPS nie działa. Jak to zmienić? Bardzo prosto. Można oczywiście wdrożyć urząd certyfikacyjny na jednym z serwerów Windows, jednak nie zawsze jest to możliwe. Tak naprawdę, do uruchomienia LDAPS na kontrolerach domeny możemy użyć dowolnego urzędu CA, do którego mamy dostęp, żeby wygenerować potrzebne nam certyfikaty. Dobra instrukcja, jak to zrobić znajduje się na stronach wikipedii Technet. Możemy jednak postąpić jeszcze prościej - użyć certyfikatów self-signed. Tak naprawdę do uruchomienia LDAPS certyfikaty muszą spełniać 3 warunki:

1. Certyfikat musi obsługiwać funkcję Server Authentication. Czyli innymi słowy musi zawierać Server Authentication OID: 1.3.6.1.5.5.7.3.1
2. Atrybut Subject Name lub pierwsza nazwa w atrybucie Subject Alternative Name (SAN) musi  być zgodna z nazwą Fully Qualified Domain Name (FQDN) serwera - np. SubjectCN=server1.contoso.com
3. W lokalnym magazynie konta komputera musi znajdować się klucz prywatny certyfikatu.

Czyli możemy z linii komend wygenerować certyfikat komendą:
certreq -New -Machine policy.inf

Wcześniej oczywiście musimy sobie przygotować plik policy.inf zawierający niezbędne informacje.

Kilka przykładów prostego i bardziej rozbudowanego pliku znalazłem na blogu Oskara Virota.

Jeżeli jednak kontrolery domeny są w wersji Windows 2012 lub nowszej możemy użyć cmdleta powershell New-SelfSignedCertificate, 

Tworząc certyfikat nawet przy minimalnej ilości atrybutów uzyskamy odpowiedni wynik, chociaż certyfikat będzie miał standardową długość życia certyfikatu (jeden rok):

New-SelfSignedCertificate -DnsName "server1.contoso.com" -CertStoreLocation "cert:\LocalMachine\My"

Teraz musimy wyeksportować certyfikat (najlepiej w formacie Base64) i zaimportować go ponownie, tym razem wybierając magazyn Zaufanych Głównych Urzędów Certyfikacji, na wszystkich kontrolerach domeny, z którymi chcemy, żeby komunikacja LDAPS działała (oczywiście na nich również powinniśmy wygenerować i wyeksportować kolejne certyfikaty), oraz na bramce SMG.
Po restarcie kontrolera domeny połączenie LDAPS powinno uruchomić się bez problemów.

Współpraca Office365 z Windows Server 2012

Kilka tygodni temu sprawdzałem możliwości współpracy modelu hybrydowego dla organizacji korzystającej z Offce365 i zauważyłem, że większość dokumentacji mówi wyłącznie o DirSync-u na systemie nie nowszym niż Windows 2008R2 i ADFS 2.0 RTW (który nie jest wspierany na platformie Windows 2012) do obsługi Single SignOn. Jednak dzisiaj znalazłem informacje, wskazujące na możliwość wykorzystania Windows 2012 Standard lub Datacenter zarówno jako serwer DirSynca, jak i dla Single SignOn. W tym drugim przypadku należy pamiętać o zainstalowaniu w Windows 2012 systemowej roli ADFS (ADFS 2.1) oraz pobraniu Windows Azure AD Module for Windows PowerShell. Mam nadzieję, że w najbliższych dniach zweryfikuję to własnoręcznie.Niestety realizawana od kilku miesięcy przebudowa portalu Microsoft Technet, zwłaszcza działu Downloads, nie ułątwia znalezieniu odpowiednich informacji. Warto jednak zajrzeć na stronę Wiki technologii Azure, gdzie jest podlinkowanych dużo informacji na temat zarówno synchronizacji jak i SSO.

Active Directory Replication Status Tool

Jeśli brakuje wam w Windows 2008 repmona, albo uważacie, że użycie repadmina z linii komend jest zbyt skomplikowane, to mam dobrą wiadomość – pojawiło się nowe narzędzie na stronie pobrań Microsoft, które w formie graficznej pozwala monitorować replikację pomiędzy kontrolerami domenowymi, zarówno na poziomie domeny, jak i lasu. W odróżnieniu od repmona, lista kontrolerów wykrywana jest automatycznie (jeżeli chcemy możemy również listę serwerów podać samodzielnie, co bardzo ułatwia pracę.

Wyniki możemy bezpośrednio z konsoli wyeksportować do arkusza Excelowego, lub pliku XPS. Mamy również dostęp do pomocy technicznej, opisującej czym jest replikacja w AD i jak nią zarządzać, co dla początkujących administratorów może być bardzo pomocne.

http://www.microsoft.com/en-us/download/details.aspx?id=30005

ADFS – ciekawy e-book

Ostatnio trochę więcej czasu poświęciłem usługom federacyjnym (głównie pod kątem Office365) i właśnie znalazłem ciekawego e-booka na ten temat na stronach Microsoftu – “A Guide to Claims-Based Identity and Access Control, Second Edition”. Ciekawa pozycja opublikowana (druga wersja) w tym miesiącu, omawia różne aspekty dotyczące federacji, SSO, również integrację z Azure. Oprócz książki można pobrać również przykłady kodu, wykorzystywanego do implementacji poszczególnych rozwiązań.

GPO – jak szybko podpiąć polisę pod wiele site’ów?

Ostatnio musiałem szybko podlinkować nową polisę GPO dotyczącą specyficznych ustawień do dużej ilości lokalizacji AD. Jak to można zrobić szybko? Oczywiście odpowiedź najprostsza – Active Directory. W środowisku z aktualną wersją Windows nie jest to trudne. Można sięgnąć do grupy poleceń PowerShell dotyczących GPO - http://technet.microsoft.com/en-us/library/ee461027.aspx

W moim przypadku musiałem dla zdefiniowanej polisy przypiąć ją do wielu lokalizacji, chociaż dla różnych OU składnia wyglądałaby identycznie. Po pierwsze musiałem wyeksportować listę site’ów (jak na rysunku) z konsoli AD Sites and Services do pliku csv.

Następnie do utworzonej listy dodałem kolumnę z wartością Distinguished name (w Excelu dodanie kolumny i na podstawie nazwy site’u wygenerowanie kolumny z distingushed name).

Nagłówek pliku csv wyglądał tak jak poniżej (tylko kolumna DN została dodana przeze mnie, pozostałe są automatycznie eksportowane z konsoli):

Name;DN;Location;Type;Description

Następnie prościutka pętla w Powershellu i po kłopocie:

Import-Module grouppolicy
$allsites = Import-Csv -Path "C:\scripts\sitelist.csv" -Delimiter ";"
foreach ($site in $allsites)
{
    New-GPLink -name AV -target $site.DN -LinkEnabled Yes
}

Skrypt do listowania członków grup globalnych w domenie

Import-Module ActiveDirectory
$groups=Get-ADGroup -filter {GroupCategory -eq "Security" -and GroupScope -eq "Global"}
foreach ($g in $groups)
{ Write-Host "Members of group" $g.name
Get-ADGroupMember $g.name | Select-Object name
}

Tak dla pamięci – prosty skrypt do listowania członków grup security w domenie Windows 2008 R2.

Informacje o blokowaniu kont w AD

Pry okazji jednego z projektów wróciłem trochę (od strony admina a nie wdrożeniowca) do zagadnień zarządzania dużą ilością kont użytkowników domenowych, sprawdzania ich statusu i odblokowywania tych kont. Tak jak statystyki dotyczące wygasania haseł i modyfikacji hasła można oskryptować w PowerShellu lub VBscripcie i zrobić sobie ładne zestawienia, to jednak bardzo przydaje się zestaw gotowych narzędzi. Ale jakich?

Dla Windows 2003 można pobrać ze strony Microsoftu pakiet Account Lockout and Management Tools oraz dodatkowo aplikacja Lockout Status, która pozwala w dużej sieci sprawdzić, na którym kontrolerze domeny użytkownik zablokował sobie konto. Podstawowy komponent powyższego pakietu to biblioteka AcctInfo.dll, która dodaje do konsoli Active Directory Users and Computers kolejną zakładkę, pokazującą informacje o statusie konta, kiedy użytkownik się logował, kiedy zmieniał hasło, etc. Niestety, nie można jej zarejestrować na platformie 64 bitowej, co w zasadzie uniemożliwa jej stosowanie na platformie Windows 2008 i 2008 R2. Na szczęście powstała wersja 2 tej biblioteki, niestety niedostępna do pobrania na stronach Microsoftu w normalny sposób (jest udostępniana przez PSS tylko klientom korporacyjnym). Można jednak znaleźć ją w kilku miejscach w sieci – np. na serwisie activedir.org, który ma dla mnie wystarczającą wiarygodność.

 http://www.activedir.org/ACCTINFO2_64BIT.zip

Razem z biblioteką acctinfo2.dll w pliku znajdziemy dokument z opisem instalacii, który niestety nie polega wyłącznie na zarejestrowaniu biblioteki w systemie, ale również wymaga modyfikacji ustawień display identifiera w partycji konfiguracyjnej Active Directory (na szczęście procedura jest dobrze opisana w przewodniku instalacji). Po zakończeniu instalacji i uruchomieniu konsoli ADUC pokaze nam się dodatkowa zakładka, jak na poniższym rysunku:

Oczywiście, możemy uznać, że wystarczy nam zakładka “atribute editor”, dostępna w systemach Windows 2008/2008R2, ale przedstawione tam informacje nie są tak przejrzyście uporządkowane, co wymaga większej uwagi i wiedzy od administratora.

Nowy BPA dla usług DNS

Fakt, że w Windows 2008 R2 możemy dla każdej z ról serwerowych skorzystać z Best Practices Analizatorów, już chyba nikogo nie zaskakuje. Powoli jednak nabiera rumieńców bardziej uniwersalne narzędzie – Microsoft Baseline Configuration Analyzer 2.0, do którego pojawiają się kolejne moduły, umożliwiające analizę konfiguracji poszczególnych aplikacji. Właśnie pojawił się moduł do analizy konfiguracji usług DNS – co na pewno dla administratorów Active Directory, którzy jeszcze nie zaktualizowali kontrolerów do wersji 2008 R2 jest bardzo przydatnym narzędziem.

Best Practice:Active Directory Structure Guidelines

Ciekawy artykuł o tym jak projektować i jakich błędów unikać przy tworzeniu struktury OU znalazłem na witrynie Group Policy Center napisany przez Alana Burchilla. Zachęcam do lektury.

Group Policy Center » Blog Archive » Best Practice:Active Directory Structure Guidelines – Part 1

OCS 2007 R2 działa na Windows Server 2008 R2!

Microsoft obiecał możliwość współpracy OCS 2007 R2 i Windows 2008 R2 w 1Q 2010 i w ostatniej chwili spełnił swoją obietnicę – artykuł http://support.microsoft.com/kb/982021/ opisuje jak zainstalować OCS 2007 R2 na Windows 2008 R2. Drugi artykuł http://support.microsoft.com/kb/982020/ opisuje rozwiązanie problemu z pracą OCS lub LCS 2005 po aktualizacji kontrolerów domeny do wersji 2008 R2.

Lista portów wykorzystywanych w aplikacjach Microsoft

Jednym z częstych pytań, dotyczących nie tylko Exchange jest lista portów, które trzeba odblokować na firewallu, żeby nasze aplikacje działały poprawnie. Jest odpowiedni artykuł bazy wiedzy Microsoft, który podaje odpowiedź na to pytanie, jak widać po numerze (35.1) wielokrotnie poprawiany i uzupełniany.

Service overview and network port requirements for the Windows Server system

Directory Experts Conference Europe 2007

Wczoraj znalazłem informację o o europejskiej edycji ciekawej konferencji, na którą nie udało mi się wybrać do Stanów. Może do Brukseli będzie łatwiej. Chociaż cena nie jest najniższa:( Dla zainteresowanych zamieszczam agendę, niestety bardzo uproszczoną:

24 September 2007

• Conference, 8:30 - 17:15
• Welcome Reception, 18:00

25 September 2007

• Conference, 8:30 - 17:15
• Reception, 18:00
• Dinner, 19:00

26 September 2007

• Conference, 8:30 - 17:15
• Send-Off, 17:30

Directory Experts Conference Europe 2007