K-NET s.c.

Błąd 2221 – mapowanie dysku

Chciałem dzisiaj napisać o problemie z jakim spotkałem się przed kilkoma dniami. Problem dotyczył podłączenia (mapowania) zdalnego udziału sieciowego w domenie Active Directory. Proces kończył się zawsze komunikatem – błąd 2221. Było to o tyle dziwne zachowania, że:

1. Problem dotyczył tylko wybranego użytkownika na wybranej stacji (w tym przypadku laptopie). Zalogowanie się na innym komputerze jako ten sam użytkownik umożliwiało podłączenie wspomnianego udziału.
2. Zalogowanie się z uprawnieniami adminstratora na feralnej stacji powodowało, że ten sam udział można było mapować bez żadnego problemu.
3. Najdziwniejsze zaś było to, że udział nie mapował się przy użyciu nazwy domenowej serwera, zaś jeśli użyłem adresu IP to wszystko działało dobrze, nawet na koncie wspomnianego użytkownika.

Jest to dość subtelny błąd i trudno było znaleźć jednoznaczane rozwiązanie. Niemniej po jakimś czasie okazało się, że kłopot sprawia bufor (cache) przechowywujący lokalnie nazwy użytkownika i związane z nimi hasła. Po jego wyczyszczeniu wszystko wróciło do normy. Poniżej krótki przepis co należy zrobić.

Uruchamiamy Panel sterowania, wybieramy Konta użytkowników a następnie opcję Zarządzaj poświadczeniami. Teraz pozostaje nam odnaleźć nazwę użytkownika (konta) i usunąć poświadczenia zapisane przez system.

Konfigurowanie użytkowników systemowych na serwerze Samba w środowisku Active Directory

Praktyka związana z budowaniem sieci komputerowych w małych i średnich firmach pokazuje, że często jesteśmy zmuszeni tworzyć środowiska heterogeniczne, gdzie np. domena Active Directory AD współpracuje z linuksowym sewerem plików Samba SMB. Aby ten dość często spotykany tandem był w pełni funkcjonalny dobrze jest zintegrować bazę użytkowników AD z kontami dla serwera SMB. Nie chcę tutaj poruszać problemów związanych z samą konfiguracją po stronie Linuksa – jest to wielokrotnie omawione w sieci (jeden z najlepszych poradników howto można znaleźć pod tym adresem). Tym razem chciałbym pokazać jak rozdzielić na serwerze Debian użytkowników AD od systemowych.

W przypadku integrowania serwera plików z domeną mamy dwie możliwości:

• albo wszystkie konta będą przechowywane w katalogu Active Directory
• albo na serwerze linuksowym pozostawimy część natywnych kont systemowych

Osobiście zawsze wybieram tą drugą opcję, chociażby dlatego aby uniezależnić niektóre usługi systemowe od domeny. Takie podejście bywa często krytykowane, szczególnie przez zwolenników centralnego zarządzania. Niemniej jest spotykane i stosowane. Problem z opisywaną konfiguracją polega na tym, że łącząc nasz serwer z domeną musimy włączyć protokół uwierzytelniania Kerberos. Przy standardowej konfiguracji oznacza to, że wszyscy użytkownicy o identyfikatorze UID większym równym 1000, będą autoryzowani na poziomie domeny (oznacza to, że np. nie zadziałają prawidłowo polecenia passwd i useradd).

Jak zwykle w takich przypadkach istnieje wiele rozwiązań, o czym można przekonać się poszukując materiałów w sieci. Niemniej najprostszym i prawdopodobnie najszybszym będzie wyedytowanie pliku/etc/pam.d/common-password. Następnie należy zmienić wartość paramteru minimum_uid (która domyślnie wynosi 1000):

password requisite pam_krb5.so minimum_uid=2000

Powyższy wpis oznacza, że odtąd użytkownicy LDAP (którzy w tym przypadku są użytkownikami AD) mają identyfikatory UID zaczynające się od 2000, zaś lokalny administrator linuksowy może spokojnie operować na kontach systemowych.

MG

Rola rekordu SRV w konfiguracji MS Exchange

Microsoft Exchange Server jest obecnie jednym z popularnych serwerów pracy grupowej w firmach. Nie jest to rozwiązanie tanie. Szczególnie jeśli uwzględnimy koszt budowy infrastruktury zgodnie z zaleceniami Microsfotu, koszt licencji dostępowych CAL itd. Tak czy inaczej jeżeli zdecydowaliśmy się już na zakup oprogramowania i nie mamy kilku serwerów do wykorzystania musimy liczyć się z koniecznością gruntownego zabezpieczenia naszego głównego serwera Exchange. Konfiguracja, o której mówie zakłada zainstalowanie 3 głównych ról serwera (Hub Transport Server, Mailbox Server oraz CAS – Client Access Server) na jednym serwerze. W omawianym przypadku nie zajmujemy się serwerem brzegowym (Edge Transport Server).

Ponieważ na wspomnianym serwerze instalujemy usługi dostępowe CAS (w tym dla klientów mobilnych, z poza sieci firmowej) należy zabezpieczyć go wszelkimi możliwymi środkami. Najprostszym i najtańszym rozwiązaniem jest zorganizowanie komunikacji z wykorzystaniem protokołu HTTPS (port 443). Klient poczty Microsoft Outlook posiada możliwość połączenia się z serwerem Exchange za pomocą tandemu RTP over HTTPS. Można zatem łatwo dodać regułę na firewallu firmowym, umożliwiącą komunikację z zewnątrz z serwerem Exchange na porcie 443.

Niestety Outlook wykorzystuje często funkcje autokonfiguracji działającą w oparciu o usługę Autodiscover. W tym miejscu dochodzimy do sedna problemu opisywanego w tym artykule. Jeżeli domena Active Directory (np. corp.firma.com) różni się od domeny internetowej (np. firma.com) to Outlook będzie zasypywał nas komunikatami o błędach. Istnieje wiele sposobów zapobiegania takim sytuacjom. Jednym z najbardziej skutecznych jest wykorzystanie rekordu SVR na zewnętrznych serwerach nazw. W ten sposób Outlook z każdego miejsca w internecie będzie mógł połączyć się z naszym serwerem Exchange. Rekord SRV dla Exchange będzie miał następującą postać (użyłem przykładu dla popularnego serwera bind):

_autodiscover._tcp.firma.com. IN SRV 0 5 443 server.corp.firma.com.

Musimy jeszcze pamiętać o rekordzie A dla domeny z przykładu – firma.com:

server.corp IN A 1.2.3.4

Takie rozwiązanie pozwoli uniknąć w przyszłości chóru narzekających użytkowników. I o to w zasadzie w tym wszystkim chodzi…

MG

Dlaczego musiałem zdegradować kontroler domeny Windows 2008 R2

Przez wiele lat byłem użytkownikiem Windowsów. Pamiętam takie czasy gdy Windows NT w wersji 4.0 był dla mnie podstawowym narzędziem pracy. Udało mi się nawet bezawaryjnie obsługiwać jedną z domen NT przez 10lat  (taki osobisty rekord w kategorii najdłużej działających serwerów bez zwisów, serwer dostarczał DHCP, DNS, WWW i pocztę elektroniczą). Potem nastał czas Unixa, Linuxa i tak aż do tego roku. Historia lubi zataczać koło i zostałem zmuszony do przypomnienia sobie paru rzeczy, nauczenia się nowych oraz odświeżenia znajomości z domenami Active Directory.

Razem z kolegą zaprojektowaliśmy i wykonaliśmy mała domenę AD na zlecenie. Głównymi jej elementami były dwu węzłowy klaster MS SQL, dwu węzłowy klaster HyperV przeznaczony na wirtualną maszynę z MS Exchange. Żeby całość funkcjonowała prawidłowo potrzebny był oczywiście jeszcze kontroler domeny. I tutaj zaczeły się schody. W opisanym wcześniej przypadku pojedynczy kontroler stanowi najsłabszy element sieci. Praktycznie wszystkie usługi domenowe korzystają z baz utrzymywanych przez kontroler. Nie musi to być najbardziej wydajna maszyna, powinna być jednak dobrze zabezpieczona. Ponieważ w międzyczasie zleceniodawca zdecydował się na dodanie do domeny jeszcze jednego serwera, potrzebnego do implementacji CRM, wpadłem na pomysł, że nadarza się okazja zaimplementowania na nim dodatkowego kontrolera domeny. Nic bardziej błędnego! Główne powody, dla których nie należy tak robić to:

• Komputer, który jest kontrolerem domeny nie ma możliwości dodawania użytkowników lokalnie
• Jeśli oprogramowanie instalowane na kontrolerze domeny dodaje nowe konta to stają się one kontami domenowymi
• Nie możemy ograniczyć uprawnień dla np. operatora serwera (odpowiedzialnego za lokalną usuługę np. wspomniany CRM) na tyle aby nie był on w  stanie zaszkodzić domenie

Wniosek jaki stąd płynie brzmi – jeśli myślisz o dodatkowych usługach w swojej domenie np. IIS, CRM itd. to instaluj je na serwerach będących wyłącznie członkami domeny (domain members). Pomio różnych opinii spotykanych w Internecie na ten temat skłaniam się ku kategorycznemu stwierdzeniu, że kontroler domeny powinien pozostać wyłącznie kontrolerem domeny. Jeśli sieć ma być w miarę bezpieczna rzecz jasna. A to z kolei prowadzi do wniosku, że projektując domene trzeba przyjąć, że co najmniej 2 serwery musimy przeznaczyć do tej roli. A więc płacz i płać:(

Nawiązując do tematu wpisu dałem złapać się w pułapkę i dlatego musiałem zdegradować (w dokumentacji technicznej Microsftu ta czynność nazywa się depromoting) całkiem zgrabny kontroler domeny. Poradnik jak to zrobić można znaleźć na stronie Microsoft TechNet w artykule “Removing a Domain Controller from a Domain“. Zanim jednak zaczniemy działać należy się upewnić, że:

1. Nie usuwamy ostatniego kontrolera w domenie (praktycznie oznacza to, że w sieci musi być jeszcze co najmniej jeden serwer przechowywujący Katalog Globalny GC) co nieodwracalnie ją zniszczy
2. Nie usuwamy podstawowego serwera DNS dla domeny Active Directory (jeśli tak to trzeba wcześniej przenieść tą rolę na inny serwer zawierający Katalog Globalny GC)

MG