Miesiąc: czerwiec 2010

dziwne wymagania hasła

jedne z najdziwniejszych wymagań na hasło – strona zgłaszania problemów ze sprzętem HP:

eN.

terminale (DoD combo)

od kilku dni prześladuje mnie technologiczny diabeł. nie wnikając w szczegóły takie jak ciągłe zrywanie nowego łącza (tepsa …) przez kilka dni,  padnięta żarówka w projektorze, przegryziony kabel audio przez kota, laptop, który przestaje działać, samochód , który mi robotnicy zepchnęli na trawnik, przyjechała straż miejska i wlepiła mandat za parkowanie na trawie… to tylko niektóre z przyjemności, które mnie testują. bardziej mistyczne skojarzenie może dotyczyć Hioba, bardziej naukowe – teoria chaosu wprowadza pojęcie “dziwnego atraktora” który w tym momencie idealnie do mnie pasuje – jestem gdzieś na rozwidleniu fraktala złych przypadków i z niecierpliwością czekam na zmianę dynamiki, bo moje umiejętności życia w stresie i pracy po kilkanaście.. dziesiąt (; godzin dziennie są u skraju wyczerpania…

zacznę od  przypadku serwera terminalowego, stojącego na w2k8 R2. jest tu dużo ciekawostek, które warto sobie poczytać – bo jest kilka ciekawostek i przynajmniej część jest wyjaśnialnych… serwer był niedawno migrowany. nie sposób opisać wszystkie problemy jakie miały miejsce przez ostatnie dni – ale niektóre wnioski mogą się przydać innym.

błąd 1 – replikacja i UIDy?

ponieważ serwer terminalowy należał do grupy “Terminal Server License Servers” oraz miał atrybut “trust for delegation” zostałem poproszony o dodanie nowego serwera nie usuwając obiektu w AD. komputer dodał się bez problemów i wszystko niby działało…. po jakimś czasie serwer odrzucał połączenia z komunikatem ‘Access Denied’ podczas, gdy w logach można było sprawdzić, że użytkownik uwierzytelnił się prawidłowo. jedyny sygnał jaki wskazywał na nieprawidłowości były ostrzeżenia, że komputer nie należy do grupy TSLS. ponieważ widzę w AD, że należy postanowiłem sprawdzić co o tym sądzi sam serwer.

jak sprawdzić przynależność komputera do grup?

dla usera prosta: ‘whoami /all’. uruchomienie konsoli w kontexcie konta systemowego i zrobienie tego samego, nie daje niestety odpowiednich rezultatów. najprostszym sposobem jest wykorzystanie ‘gpresult /scope computer /r’, który okazał się przy całym debugowaniu bardzo przydatnym narzędziem. próbowałem wyciągnąć bardziej dokładne informacje – ale nawet wszystkie toole do kerberosa – jak np. klist – są zrobione wyłącznie z myślą o kontach użytkownika. to imho duże niedociągnięcie [po cichu liczę, że te wypociny przeczyta Gibon i wyciągnie jakiegoś królika z kapelusza mocno mnie zawstydzając, ale z pożytkiem dla przyszłych tego rodzaju problemów (; ].

jak nie trudno się domyśleć komputer nie był tak na prawdę w grupie TSLS. poprosiłem admina z centrali [o ileż łatwiej jest kiedy ma się domain admina… chyba muszę w końcu zesniffować hasełko… ] żeby konto kompa re-dodał do tej grupy. nie pomogło. finalnie usunięty został z AD i dodany ponownie [ergo utworzenie nowego obiektu]. też nie pomogło.

samo dodanie do domeny to też oddzielna historia. po usunięciu i dodaniu serwer zrestartował się wstał poprawnie i nawet pozwolił się zalogować… ale coś było nie tak – search po AD i okazuje się, że konto w domenie nie istnieje. tutaj znów przydał się gpresult – ponieważ oprócz przynależności do grup, wyświetla distinguished name, czyli położenie w strukturze OU. wbrew oczekiwaniu iż trafi do defaultowego kontenera gdzie są nowe konta – wykrywał się na nieistniejącym koncie w starym OU. przy kolejnej próbie było podobnie, tylko nie pozwolił się już zalogować. w końcu grzecznie odczekałem 1o minut aż się wszystko zsynchronizuje [zrepliqje ładnie] i poszło.

błąd 2 – event 41o5 i grupa Terminal Server License Servers

problemy z terminalami niemniej nie ustały – z dokładnie takim samym efektem – czysto w logach, Access Denied przy próbie logowania. jedyny wpis to Event 41o5:

Log Name:      System
Source:        Microsoft-Windows-TerminalServices-Licensing
Date:          2010-06-16 15:41:55
Event ID:      4105
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      RDS.my.domain
Description:
The Remote Desktop license server cannot update the license attributes for user "username" in the Active Directory Domain "my.domain". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "my.domain".
If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Remote Desktop Licensing service to track or report the usage of RDS Per User CALs.
Win32 error code: 0x80070005
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-TerminalServices-Licensing" Guid="{4D99F017-0EB1-4B52-8419-14AEBD13D770}" EventSourceName="TermServLicensing" />
    <EventID Qualifiers="51456">4105</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2010-06-16T13:41:55.000000000Z" />
    <EventRecordID>5442</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>System</Channel>
    <Computer>RDS.my.domain</Computer>
    <Security />
  </System>
  <UserData>
    <EventXML xmlns:auto-ns3="http://schemas.microsoft.com/win/2004/08/events" xmlns="Event_NS">
      <param1>username</param1>
      <param2>my.domain</param2>
      <param3>0x80070005</param3>
    </EventXML>
  </UserData>
</Event>

błąd się zgadza: ox8oo7ooo5 to acc denied. kolejna ciekawostka to fakt, że część połączeń przyjmuje a odrzuca dopiero po jakimś czasie. do debugowania problemów z licencjami termina
lowymi jest tool “RD Licensing Manager” więc zacząłem sprawdzać. pierwszy błąd wykryłem szybko – zamiast licencji “PER USER” zainstalowane były licencje “PER DEVICE” czego nie zweryfikowałem pierwotnie. telefon do centrali, dodane. tutaj przydatna informacja:

“Per User CALs are not monitored by Terminal Server. This means that even though there is a Per User CAL in the license server database, the Per User CAL is not decremented when it is used. Additionally, if you use the Per User licensing mode, when a client logs on to a terminal server for the second time, the temporary license is not upgraded to a permanent CAL.”

co oznacza nie mniej ni więcej – że User CAL nie są weryfikowane a więc nawet jeśli przekroczy się liczbę licencji – powinien normalnie wpuszczać. informacja jest dla wersji w2k3 i nie znalazłem póki co ani potwierdzenia ani zaprzeczenia tej informacji dla w2k8.

ponieważ to nie poskutkowało oczekiwanym rezultatem zacząłem szukać dalej i znalazłem drugi błąd. po włączeniu ‘review config’ okazało się, że tutaj w końcu serwer normalnie pokazuje, że nie należy do TSLS [niby zgodnie z tym, co wie o sobie komp].

kolejny telefon do centrali ‘please clik it!’ i już. restart, zaglądam do AD i okazuje się, że wbrew komunikatowi, serwer nie musi należeć tylko do TSLS ale również do “Terminal Server Computers”. dopiero wtedy RD License Manager przestał pokazywać ostrzeżenia… co nie zmieniło faktu, że nadal pojawiają się Event 41o5 w logu systemowym a gpresult nadal nie widzi grupy TSLS [SIC!] przy czym póki co userzy się mogą logować. niemniej obawiam się, przy ostatniej fali ciekawostek to nie jest niestety jeszcze koniec historii ): żeby było zabawniej poprzedni serwer różnił się w konfiguracji wyłącznie tym, że był na innym sprzęcie i w wersji enterprise – co zaczyna coraz bardziej skłaniać do wniosq, że problem leży w pierwszej warstwie [oj, jak ja tego nie lubię].

czas zbudować LABa – może on nie ma widzieć tej grupy? ROTFL

błąd 3 – w-files

prawdziwe w-files. ni-stąd-ni-z-owąd katalogi poprzemieszczały się na file serwerze. uruchomione zostały wszystkie procedury bezpieczeństwa i testy spójności – generalnie *coś* się stało z system plików. imho to wina McAfee AV – bo generalnie ten produkt doprowadza mnie do furii a po odinstalowaniu serwer zaczął działać lepiej (subiektywne wrażenie). tak czy inaczej muszę cały serwer stawiać od nowa. procedury odzyskiwania i reperacji potrwają w sumie około 48 godzin. no to jedna nocka w firmie, teraz będzie druga. a zaczął się WEF qrde! ):

przy okazji odkryłem jeszcze jedną ciekawostkę – plik, którego nie da się skasować. wygląda jakiś tymczasowy od office bo ma taką samą nazwę jak dwa inne, z innymi rozszerzeniami. ten plik kończy się kropką – “.”. znalazłem co prawda opis jak obejść głupie API, które po kropce czeka na rozszerzenie:

del “\?d:directoryannoyingfilewithdotontheend.”

ale niestety w tym przypadq i tak dostaję 'file not found.’. próbowałem już różnych sztuczek – np. powershell zachowuje się tak samo. póki co zostaje taki śmieć.

błąd 4 – DHCP

podręcznikowo jeśli na chwilę wyłączy się serwer DHCP – nie powinno być problemów – nowe stacje co prawda nie dostaną numerka, ale te co już mają, powinny sobie działać, aż do restartu. w rzeczywistości z jakiegoś niewyjaśnionego powodu nie dość, że duża część Windowsów (nawet w7) po wyłączeniu serwera DHCP zrzuca numer i bierze z APIPA [SIC!!!] – co już jest porażką, to nawet jeśli włączony jest zastępczy z identycznymi pulami [ale oczywiście ma inny IP] – nie potrafi sobie tego numerka pobrać! dopiero wykonanie ipconfig /renew odświeża adres ale do tego trzeba mieć uprawnienia administratora na stacji! to zachowanie jest potwornym zagrożeniem i w zasadzie uniemożliwia zapewnienie ciągłości pracy w przypadq prac na serwerze z rolą DHCP.

niestety – to be continued…

dziwny atraktor eN.