Domain Contorllers/Домейн Контролери - PDC - Primary Domain Controller

Домейн контролери

Всички домейн контролери по пъщество са еднакви с две изключения. RODCs/Read Only Domain Controllers/ съдържат само за четене копие от DS базата данни на AD, а другите домейн контролери имат права за четене и запис на копието. Има и някои
операции, които могат да се извършват само по конкретни домейн контролери, наречени operation masters.

Домейн контролер е сървър, който е конфигуриран да съхранява копие от AD DS директория на базата данни(Ntds.dit) и копие от папката SYSVOL. Всички домейн контролери с изключение на RODC съхраняват копие от Ntds.dit както и SYSVOL папките. Ntds.dit е самата база данни, а SYSVOL папка съдържа всички настройки на шаблона и файлове за GPOs.

Домейн контролерите използват мулти-мастър репликация процес. За повечето операции, данните могат да бъдат променени на всеки домейн контролер с изключение на RODCs. AD DS репликация синхронизира промените, които са направени на базата данни на АД към всички други домейн контролери в домейна. Папките SYSVOL се репликират или чрез услугата за репликация на файлове (FRS), или от Разпределена файлова система (DFS).

Домейн контролерите имат и няколко други услуги включително Kerberos
удостоверяване на услуги, който се използва от потребители и компютри за влизане в системата и удостоверяване.

Всички потребители в AD съществуват в базата данни на АД и ако базата данни е недостъпна поради някаква причина, всички операции зависими от удостоверяване в домейна ще се провалят. Като най-добри практики трябва да има минимум два домейн контролера. Това поддържа висока наличност на базата данни на АД и се разпространява от натоварването на удостоверяване по време на пиковете при логване.
Когато използваме домейн контролер в клон, където физическа сигурност е по-слаба от оптималното, има някои допълнителни мерки, които можете да използвате, за да се намали нарушаването на сигурността. Единият вариант е да се използват RODC.

Тези домейн контролери държат само Read-only от базата данни на Ад-то и по подразбиране
не запазват(кешират) данни за потребителските пароли. Така ако този тип домейн контролер е изложен на риск, вероятността за загуба на данни е много по-малка.

Друг вариант е да използвате Windows BitLocker® за шифроване на устройства и за кодиране на хард диска  на домейн контролера. Ако хард диска е откраднат, BitLocker криптирането гарантира,  много малък шанс на злонамерен потребител да получи полезна информация от него.

BitLocker е система за криптиране за Windows Server операционни системи, както и за някои версии за клиентска операционната система. BitLocker криптира цялата операционна система, така че компютърът не може да започне, без да бъдат въведен частен ключ.. A диск остава криптирана, дори ако се закачи и прехвърли на друг компютър.

PDC - Основен домейн контролер

Чрез основния домейн контролер или PDC е основния източник се синхронизират часовете на всички други домейн контролери на всеки домейн във фореста.

Също така той отговаря и при спеша смяна на пароли. Ако потребител си смени паролата, информацията веднага се изпраща до Основния домейн контролер и ако потребител се опита да се логне и да се аутентикира през домейн контролер на различно местоположение, който още не е получил информация за промяната на паролата, въпросния домейн контролер ще се допита първо по PDC за скорошни промени. Ако основния домейн контролер е недостъпен по различни причини, потребители ще имат проблем с логването ако информацията не се е репликирала по останалите контролери.

PDC също се използва при промяна на GPO-тата. Когато групова политика различна от локална е отворена за промяна, копието, което се променя се съхранява на PDC. Това се прави с цел предотвратяване на конфликт ако двама администратори се опитват да променят една и съща групова политика по едно и също време на различни домейн контролери. Може да се избира на кой домейн контролер да се променят груповите политики. Това се използва, когато се променят политики в отдалечен офис с бавна връзка към основния домейн контролер.

NAT/What is Network Address Translation?

Network Address Translation (NAT) е процес, при който мрежово устройство, обикновено защитна стена, назначава обществен адрес на компютър (или група от компютри), вътре в частна мрежа. Основното приложение на NAT е да се ограничи броят на обществените IP адреси на организация която се използва, както за икономия така и за сигурността цели.

Най-често срещаната форма включва голяма частна мрежа с помощта на адреси в частен кръг (10.0.0.0 до 10.255.255.255, 172.16.0.0 до 172.31.255.255, или 192.168.0 0 до 192.168.255.255).
Тази схема работи добре за компютри, които имат достъп до ресурсите в рамките на мрежата, като настолните компютри, които се нуждаят от достъп до файлови сървъри и принтери. Маршрутизаторите вътре частна мрежа може да маршрутизират трафика между частни адреси без проблеми с. Въпреки това, за да получите достъп до ресурси извън мрежата, като Интернет, тези компютри трябва да имат публичен адрес, за да отговори на техните искания. Това е мястото, където NAT влиза в игра.

Интернет заявки, които изискват Network Address Translation (NAT) са доста сложни, но се случват толкова бързо, че крайният потребител рядко знае за тях. Работната станция вътре в мрежата отправя искане към компютър в Интернет. Маршрутизаторите в рамките на мрежата, признават, че искането не е за ресурсите в рамките на мрежата, така че те да изпрати искане до защитната стена. Защитната стена вижда искане от компютъра с вътрешния IP. След това той прави същото искане към Интернет, използвайки собствения си публичен адрес и връща отговор от страна на интернет ресурса на компютъра вътре в частната мрежа. От гледна точка на ресурса в Интернет, тя се изпраща информация на адреса на защитната стена. От гледна точка на работната станция, се оказва, че комуникацията е директно със сайта в Интернет. Когато NAT се използва по този начин, всички участници във вътрешността лично достъп до мрежата Интернет имат един и същ IP адрес, когато използват интернет. Това означава, че само един публичен адреси е нужен за стотици или дори хиляди потребители.

 Nat може да се използва, за да се позволи селективен достъп до външната страна на мрежата. Работни станции или други компютри, които изискват специален достъп извън мрежата могат да им бъдат възложени специфични външни IP адреси, използващи NAT, което им позволява да общуват с компютри и приложения, които изискват уникален публичен IP адрес

NAT е много важен аспект на защитна стена за сигурност. Тя запазва броя на публичните адреси, използвани в рамките на организацията, и това дава възможност за по-строг контрол на достъпа до ресурси от двете страни на защитната стена.

DNS - система за именуване

Чрез IP адресите се осъществява дресирането на дейтаграмите, които носят в себе си данните.Неудобното е, че те са числа и трудно се запомнят. Затова се въвежда система за именуване– DNS.


Domain Name System

Domain Name System (DNS) е йерархична разпределена база от данни.

Тя съхранява информация за съотвтствието между Internet хост имена и IP адреси и обратно,

информация за маршрутизиране на ел. поща и др.данни, използвани от Internet приложения.

Клиентите търсят информация в DNS, извиквайки resolver library, която изпраща заявки до един от сървърите за имена (name servers) и интерпретира отговорите.BIND софтуерът съдържа сървър за имена named, и две библиотеки - resolver libraries: liblwres и libbind.

ISC BIND



BIND (Berkeley Internet Name Domain) е реализация на DNS протоколите и осигурява отворена система за редистрибуция на основните компоненти на Domain Name System:



- Domain Name System server (named);



- Domain Name System resolver library;



- средства за верифициране на



операциите на DNS server.







Домейни и имена на домейни



Данните, съхранени в DNS са domain names, организирани в дървовидна структура. Всеки възел в дървото се нарича domain и му се дава етикет. Името на домейна във възела е поредица от етикетите, показващи пътя от възела до корена (root). В писмена форма се представя като низ от етикети, от дясно наляво, разделени с точки.



Домейните представляват области от имена. Домейните са от първо, второ и трето ниво.
(Ако не се брои root.) Няма пречки да има домейни от четвърто ниво, но те почти не се използват. Основният домейн е така нареченият root домейн. Той няма име и е един единствен. Представя се с точка. Под него се нареждат домейните от първо ниво, top-level domain (TLD). Управлението на TLDs е делегирано на азлични организации от страна на ICANN, която менижира IANA, и е отговорна за DNS root зоната. Най-често използвани TLDs са: generic top-level domains (gTLD) – отворени за регистрация за всеки. В началото всички те са в САЩ, но после в тях влизат още много имена на обекти извън САЩ, те нарастват твърде много.




Затова се въвежда друга голяма група от домейни на първо ниво, свързани с географското разположение по държави – uk, de, bg и др. Това са country-code top-level domains (ccTLD),


показващи принадлежност към държава. Състоят се само от две букви. В повечето случаи съвпадат скода на страната по ISO 3166. infrastructure top-level domain: Има само една TLD - Address and Routing Parameter Area (ARPA). Управлява се от IANA и има отношение към обратния резолвинг. Цялостното име, което включва домейните и обекта се нарича


URL (uniform resource locator). В това URL bg е името на домейна от първо ниво, uni-sofia е името на поддомейна на bg от второ ниво, fmi е името на домейна от трето ниво www е web-сървъра от домейна fmi, http е мето на протокола по който клиента се свързва към съответния обект. Колкото са точките в едно URL, толковата са нивата на домейните без да се брои root.


В URL точката на root се пропуска (подразбира се).



Resolving



DNS е йерархична именна система с три компонента – именно пространство (как сеизграждат имената), resolver-и и именни сървъри (name servers). Resolver-те са абонатите в Internet, които знаят URL и искат да получат съответния IP адрес. Процесът на преобразуване се нарича


resolving. Той се извършва от DNS протокола.



DNS протокол



DNS основно използва User Datagram. Protocol (UDP) на порт 53 за обслужване на заявки. DNS заявките се състоят от една единствена UDP заявка от клиента, последвана от един единствен UDP отговор от сървъра.







DNS протокол



Transmission Control Protocol (TCP) се



използва, когато в отговора се съдържат



повече от 512 bytes или при трансфер на



зони.



Някои операционни системи като HP-UX



използват TCP за всички заявки.







Зони



За по-лесно администриране пространството с имената



е разделено на области, наречени зони (zones)



Всяка зона започва от възел и се простира надолу до



“листата” (leaf nodes) или до възли, където стартират



други зони.



Данните за всяка зона се съхраняват в сървър за имена



(name server), който отговаря на запитвания (queries)



в рамките на зоната, използвайки DNS протокол.



Данните, които са обвързани с всяко име на домейн, се



съхраняват под формата на ресурсни записи,



resource records (RRs).







Зони



От особена важност е да се разбере разликата между зона и



домейн, за да се вникне в същността на сървъра за имена.



Зона е точката на делегиране на DNS дървото.



Зоната се състои от тези последователни части от дървото на



домейните, за които сървърът за имена има пълна информация



и върху която има власт.



Състои се от всички имена на домейни, от дадена точка надолу по



дървото с изключение на тези, които са делегирани на други



зони.



Точката на делегиране се маркира с един или повече записа:



NS records, в родителската зона, които трябва да съвпадат с



еквивалентни NS записи в корена на делегираната зона.







Зони



Напр., да вземем домейна example.com, който включва имена като



host.aaa.example.com и host.bbb.example.com.



example.com зоната включва делегирания за зоните



aaa.example.com и bbb.example.com.



Една зона може да съответства точно на един единствен домейн,



но може и да включва само част от домейна.



Като останалата част от него да бъде делегирана на други



сървъри за имена.



Всяко име в DNS дървото е domain, даже ако е terminal, т.е няма



subdomains (поддомейни). Всеки поддомейн е домейн и всеки



домейн с изключение на root (коренния) е също поддомейн.



Терминологията не е интуитивна, за по-по-добро разбиране



прочетете RFCs 1033, 1034 и 1035.







master и slave зони



Макар че BIND се нарича "domain name server",



той се занимава предимно със зони.



Декларациите master и slave във файла



named.conf определят зони а не домейни.



Ако питате някой друг сайт дали иска да бъде



slave сървър на вашия domain, вие всъщност искате.







Видове зони



Master Сървърът чете данните за зоната директно



от локалния диск (т.е от zone file) и е овластен да



дава отговори за тази зона.



Hint В тази зона се дефинират root-servers.



Slave Зона slave е реплика на master зона и



получава данни за тази зона чрез зонов



трансфер. slave ще даде овластен отговор за



зоната, само ако има валидни (не timed out) данни



за зоната.



Редът masters определя IP адрес/и на master



сървър/и, с които slave контактува, за да refresh



или update копие на зоната.







Authoritative Name Servers



Всяка зона се обслужва най-малко от един



овластен сървър за имена (authoritative name



server), който държи всички данни за зоната.



За по-висока надеждност се препоръчва зоната



да има два или повече такива сървъри.



В отговорите на authoritative servers, в пакета с



отговора, е вдигнат бит "authoritative answer"



(AA). Така по-лесно се диагностицират



(debugging) DNS конфигурациите с



инструменти като dig.







Primary Master



authoritative server, където се поддържа



главното (master) копие на данните за зоната.



Нарича се primary master сървър или просто



primary.



Той зарежда съдържанието на зоната от



локален файл, редактиран ръчно или



генериран от някакъв друг локален файл.



Този файл се нарича зонов - zone file или



master file.







Slave Servers



Другите authoritative servers, slave сървъри



(известни още като secondary) зареждат



съдържанието на зоната от друг сървър чрез



процес на репликация - zone transfer.



Обикновено данните се прехвърлят директно



от primary master, но е възможно и от друг



slave.



Т.е, slave server може да действа като master за



подчинен slave server.







Caching Name Servers



resolver библиотеките, които присъстват в



повечето операционни системи, са stub



resolvers, т.е те не са способни да изпълняват



пълния процес на DNS резолюция,



“говорейки” директно с authoritative servers.



Те разчитат на локален сървър за имена, който



да изпълнява резолюцията вместо тях.



Такъв сървър се нарича “recursive”



(рекурсивен) сървър за имена, защото



изпълнява рекурсивни търсения за сметка



на локалните клиенти.







Caching (recursive) Servers



За да се подобри производителността,



рекурсивните сървъри кешират резултатите



от търсенията, които са изпълнили.



Процесите на рекурсия и кеширане са взаимно



свързани, на термините recursive server и



caching server често се гледа като на



синоними.



Перодът от време, за който един запис се



държи в кеша, се контролира от Time To Live



(TTL) полето в него.







Caching Servers. Forwarding.



Кеширащият сървър за имена не е



необходимо да изпълнява сам пълното



рекурсивно търсене.



Вместо това той препраща (forward)



някои или всички заявки, които не може



да удовлетвори, от своя кеш към кеша



на друг сървър за имена, който се



определя като forwarder.







Многофункционални сървъри



Сървърът за имена BIND може едновременно



да бъде и master за някои зони, и slave за



други зони, и кеширащ (рекурсивен) сървър



за определен брой локални клиенти.



Все пак, функциите на овластени (authoritative)



услуги за имена и такива на caching/recursive



са логически разделени.



Затова е по-изгодно да работят на различни



машини. Така







Ресурсни записи



SOA определя кой е първичният сървър и как



се обработват данните към него.



NS съдържа информация кои DNS сървъри са



отговорни за този домейн.



MX указва име на хост, готов да приема



електронна поща в рамките на домейн.



Адресните записи съдържат съответствие



между име и IP-адрес. Имат следния формат:



<hostname> A <IP address>







Ресурсни записи



В DNS е възможно създаването на



прякори, т.е. няколко имена да



отговарят на един и същ IP адрес. Това



става с помощта на CNAME-записите,



които имат следния формат:



mail CNAME tiger



proxy CNAME tiger



tiger A 62.44.118.1







Root сървъри за имена



Кореновият сървър за имена (root nameserver) е DNS



сървър, който отговаря на запитвания относно



имената в коренния домейн и отправя заявките към



конкретни top-level domain (TLD), т.е към техните



сървъри за имена.



Всички имена в Internet завършват с точка . - напр.,



"www.wikipedia.org.” Но съвременният DNS софтуер



не се нуждае от нея, когато се опитва да транслира



домейн име в IP адрес.



Празният низ след крайната точка се нарича коренов



домейн (root domain), а всички останали (т.е. .com,



.org, .net, и т.н.) се съдържат вътре в коренния (root).







Root сървъри за имена



Когато компютър в Internet иска да открие съответствие



(resolve) за домейн име, започва от дясно на ляво,



запитвайки всеки name server поред относно



елемента от ляво.



root nameservers (отговарящи за домейна . ) знаят кои



сървъри са отговорни за top-level домейните.



Всеки такъв домейн (напр. .bg) има свой набор от



сървъри, които от своя страна делегират към



nameserver-те, отговарящи за отделните имена на



домейни (като uni-sofia.bg), които пък отговарят на



запитванията за IP адреси







Root сървъри за имена



Информацията не се променя често, затова се



кешира, така че DNS търсенията към root



nameservers са относително редки.



Но в Internet има доста некоректно



конфигурирани системи, които генерират



трафик към root servers.



Напр., заявки с източник адрес 0.0.0.0 (т.е



където и да е, навсякъде) отиват натам.



В момента има 13 root name servers, като



имената им са с формат.







Регистриране на име



Регистрирането на име не е автоматично,



а става чрез специална заявка към



регистратор за съответния домейн или



фирма, на която са делегирани



съответни права за регистрация.



За домейна .bg регистратор е register.bg.







Резолвинг на имена



За да се използва системата на URL-имената в



клиента (resolver) трябва да има агент, който



да може да работи с URL - началото на



resolving процеса.



Освен това в клиента трябва да има и малък



кеш, в който да се съхранява информация за



вече заявени и resolve-нати адреси за този



клиент.



Също така, клиентът трябва да разполага с



адрес на DNS сървър, който отговаря за



съответната област.







Резолвинг на имена



Когато към агента се подаде URL за



resolve-ане той първо проверява дали



отговора не стои в кеша.



Ако не, той изпраща заявка до DNS



сървър.



DNS сървърът може да формира три



типа заявки – рекурсивна, итеративна



или инверсна.







Рекурсивна заявка



При рекурсивна заявка DNS сървърът има прилежащ



към него друг сървър за имена.



Този сървър също може да има кеш, който евентуално



да съдържа отговора.



Сървърът може да съдържа отговора в своите зонални



файлове.



Ако и двата случая не са налице, но има конфигуриран



друг сървър за имена, той ще изпрати заявката към



него и т.н.



В един момент някой сървър по описаната верига може



да направи рекурсивната заявка в итеративна.







Итеративна заявка



При итеративната заявка сървър е в



свободното Internet пространство.



Той започва да раздробява съответното URL и



постъпково, съгласно структурата на URL



започва resolve-то.



Първо се изпраща заявка към root-сървъра,



като се иска адреса на сървъра, който



отговаря за TLD.



След това се праща заявка към сървъра от



първо ниво за адреса на сървъра, който



отговаря за домейна от второ ниво, участващ



в URL-то и т.н.







Инверсни заявки



Инверсните заявки служат за обратен resolve –



по IP адрес да се получи URL.



В сървърите за имена има специални записи,



предназначени за инверсни заявки: домейна



in-addr.arpa и (Pointer) PTR записите.



Йерархията на имената тук е спазена с



помощта на специалния домейн “INADDR.



ARPA”, разположен в резервирания



.ARPA TLD (Address and Routing Parameter Area)



“IN-ADDR” означава “INternet ADDRess”.



За IPv6 reverse lookup домейнът е ip6.arpa

DFS, DFSR / Distributed File System Replication

DFS - Distributed File System

Една от целите на най-информационните технологии е да управлява ресурсите на сървърите ефективно, като същевременно ги поддържат работещи и сигурни за потребителите. Тъй както мрежите се разширяват да се включат повече потребители и сървъри-дали те се намират в един сайт или в географски разпръснати сайтове, за администраторите става все по-трудно да държат потребителите свързани към файловете от които се нуждаят.


За да помогне на администраторите с тези проблеми, Windows Server 2003 включва Distributed File System (DFS). DFS позволява на администраторите да групират сподели папки, разположени на различни сървъри чрез свързването им към една или повече DFS namespace. DFS пространство от имена е виртуален оглед на споделени папки в една организация.

Опростена миграция на данни.

DFS опростява процеса на преместване на данни от един сървър на друг. Тъй като потребителите не е необходимо да знаят името на всеки физически сървър или споделена папка, която съдържа данните, администраторите могат физически да местят данни на друг сървър без да се налага да преконфигурират приложения и преки пътища и без да е необходимо отново да информират потребителите за това къде могат да намерят своите данни.

Повишена наличност на сървър на данни файл.

В случай на провал на сървъра, DFS отнася клиентски компютри до следващия възможен сървър, така че потребителите винаги имат достъп до споделените папки без прекъсване.

Споделяне на натоварването.


DFS осигурява степен на споделяне на натоварването чрез картографиране на дадено логическо име до споделени папки на множество файлови сървъри. Например, да предположим, че \\ Фирма \ StockInfo е силно използвана споделена папка. Администраторите могат да използват DFS да асоциира това място с много споделени папки на различни сървъри, дори и ако сървърите са разположени в различни сайтове.

Интегриране на сигруността

Администраторите не се нуждаят, да конфигурират допълнителна сигурност за DFS имената, защото сигурността на файловете и папките се осъществява от съществуващата в NTFS файловата система. Така например, потребителят навига по DFS пространство и им е разрешен достъп само до файловете или папките, за които той или тя имат подходящи NTFS права.

Distributed File System Replication

DFSR e услуга, която се използва, за да се запазят синхронизирани папки на множество сървъри.

Репликирането на данни на множество сървъри увеличава наличността на данни и дава на потребителите бърз и надежден достъп до файловете. DFSR използва нов алгоритъм за компресиране, наречен Remote Differential Compression.

Услугата DFSR използва RPC за комуникация между сървърите. Той репликира брой от папки, определена от даден път. Наборът от компютри, участващи в репликация се определя от конфигурирана топология на връзки и се нарича репликираща група.

DFSR също използва WMI да покаже мониторинг информация относно специфични обекти като репликиращи папки и връзки.