В предишната си статия обясних основните причини, поради които Microsoft реши да се върне към RODC технологията в Windows Server 2008. Тази статия продължава поредицата и ще продължим да изучаваме някои практически аспекти на работата с контролери само за четене на домейни.
Поверителни данни на потребителите
В предишна статия казах, че цялата информация за всички потребители на домейн не се прехвърля към контролерите на домейни на RODC. Всъщност информацията за потребителските акаунти все още се съхранява в RODC; потребителските пароли просто не се копират на такъв контролер на домейн. И ако някой открадне контролера на домейна от клона, той няма да може да използва информацията от базата данни на Active Directory, за да получи потребителски пароли.
Атрибути на потребителя
По подразбиране паролите са единственият атрибут на потребителя, който не се репликира до Контролер на само домейн. Възможно е обаче ръчно да се конфигурира Windows, за да се предотврати репликирането на други потребителски атрибути..
Така че в какви случаи може да се използва тази функция? Ако използвате Active Directory само като механизъм за удостоверяване, най-вероятно няма да ви е необходим. Имайте предвид обаче, че има организации, които разчитат в голяма степен на базата данни на Active Directory, която не се използва само за удостоверяване..
Доста често в големите организации, които използват различни потребителски приложения и бази данни, за да намалят броя на грешките и дублираната потребителска информация, те предпочитат да използват едно място за съхранение на цялата информация за служителите (телефони, адреси, контакти и т.н.), и страхотно място за това е Active Directory.
Например, знам една организация, която е разработила приложение за управление на персонала, което те използват в рамките на периметъра си. Въпреки че по-голямата част от данните се съхраняват в SQL базата данни, неща като имена на служители, позиции, телефонни номера и т.н. съхранявани в Active Directory като атрибути на акаунта. И в базата данни на SQL Server се съхраняват данни като TIN номера, информация за заплатите и тази база данни не съдържа имената на служителите. Единственото нещо, което свързва базата данни на AD и SQL, е номерът на служителя, който присъства и в двете бази данни.
Дадох ви този пример, за да поясня, че в редица организации поверителна информация може да се съдържа в потребителските атрибути на AD. И в случай, че такава информация не е необходима в клона, можете да блокирате репликацията му към контролера на домейна на клона.
Друга характеристика на технологията само за четене на домейн контролер е, че такъв контролер може да бъде конфигуриран и като DNS сървър само за четене. По същество това означава, че ако един атакуващ получи достъп до сървъра само за четене на домейн контролер, той няма да може да парализира корпоративния DNS.
Административни въпроси
Сигурен съм, че досега имате много въпроси относно прилагането на rodc. Ще се опитам веднага да отговоря на някои от тях.
Как се удостоверяват потребителите, ако контролерът на домейн няма информация за паролите си??
Тук има трик. Както знаете, паролата е свързана както с потребителския акаунт, така и с компютърния акаунт. По подразбиране, Read Only Domain Controller съхранява само собствената си парола (парола на компютърния акаунт) и паролата за специален акаунт, наречен „krbtgt“, който се използва от протокола Kerberos.
защото паролите не се съхраняват локално; всички заявки за удостоверяване се пренасочват към обикновен контролер на домейн, записването на което е разрешено. В случай, че искате потребителите да могат да влизат в системата, дори ако не е наличен обикновен контролер, трябва да активирате функцията за кеширане на пароли. Когато кеширането е активирано, кеш паметта ще съхранява пароли само за тези акаунти, които са удостоверени на контролера на домейна. И дори ако вашият контролер на домейн е компрометиран, вие от друг контролер винаги можете да идентифицирате тези акаунти, чиито пароли са кеширани на rodc.
Административна работа с rodc
В много клонове офисен контролер често се използва и като сървър на приложения. И в случай, че в такъв офис няма отделен ИТ специалист, можете да назначите някой от офиса за администратор на контролера rodc, без да му давате администраторски права на целия домейн (можете да прочетете публикацията за делегиране на управленски права на контролера на домейна rodc). По този начин той ще има права само на местната администрация на такъв сървър и няма да може да променя или разваля нищо в Active Directory. В резултат на това такъв потребител ще има право да инсталира актуализации на софтуера и да изпълнява други ежедневни задачи по администриране и поддържане на сървъра. Присвояването на някого като администратор на домейн само за четене е подобно на процедурата за определяне на конкретен потребител или група като локален администратор за член или самостоятелен сървър.
Връзки към всички статии от тази поредица:
Работа с контролери на домейни само за четене (RODC) (част 1)
Работа с контролер на домейн само за четене (част 2)
Работа с контролер на домейни само за четене (част 3)
