Далучэнне Azure VM да Entra Domain Services: спачатку рашэнне
Перад далучэннем стаяць тры рашэнні: мадэль каталога, патрэбная рабочай нагрузцы, прыватны DNS, які вырашае дамен, і ўліковы запіс, здольны аўтэнтыфікавацца.
Тры рашэнні стаяць перад VM з Windows Server, якой трэба выкарыстоўваць кіруемы каталог, і каманда далучэння — найменшае з іх. Абярыце няправільную мадэль каталога, і далучэнне пройдзе, а праграма ўсё адно не зможа аўтэнтыфікавацца. Памыліцеся ў развязанні імёнаў, і збой з’явіцца ў месцы, якое выглядае як праблема з уліковымі данымі.
Вызначце мадэль, развязанне і ўліковы запіс да таго, як дакрануцца да сервера, і тады каманда выканаецца адзін раз.
Якое з трох далучэнняў вам насамрэч патрэбна
Далучэнне прылады рэгіструе машыну ў Microsoft Entra ID для ўмоўнага доступу і аднаразовага ўваходу, і яно не дае рабочай нагрузцы білета Kerberos да дамена лакальнага стылю. Традыцыйнае далучэнне да дамена прывязвае аб’ект камп’ютара ў каталозе і дае яму ўліковы запіс машыны, групавую палітыку і аўтэнтыфікацыю дамена. Кіруемы дамен прадастаўляе гэтую другую мадэль як паслугу. Назвы гучаць падобна, а вынікі — не.
Толькі апошнія два ўключаюць кантролер дамена ў звычайным сэнсе, і толькі кіруемы варыянт прыбірае серверы з вашага спісу абнаўленняў.
Рашэнне звычайна залежыць ад праграмы, а не ад перавагі. Праграмнае забеспячэнне, якому патрэбна прывязка LDAP, уліковы запіс службы з SPN або аб’екты групавой палітыкі, належыць да мадэлі дамена. Праграмнае забеспячэнне, якому трэба толькі ведаць ідэнтычнасць карыстальніка на карпаратыўнай прыладзе, звычайна не належыць.
| Model | What the server gets | Where it appears |
|---|---|---|
| Entra device join | Device identity and conditional access signals | Microsoft Entra ID |
| Managed domain join | Machine account, Kerberos, group policy | The managed directory |
| Self-hosted AD DS | The same, plus every controller you operate | Your own forest |
Шлях DNS вырашае, ці зможа далучэнне завяршыцца
Далучэнне да дамена пачынаецца з пошуку лакатара для запісаў кантролераў дамена, таму развязанне імёнаў мусіць працаваць да любой праверкі ўліковых даных. Накіруйце VM на адрасы каталога кіруемага дамена — праз налады DNS віртуальнай сеткі або праз умоўны перанакіравальнік, які пасылае туды толькі гэтую прастору імёнаў. Перанакіравальнік, абмежаваны прасторай імёнаў, звычайна бяспечнейшы, бо пакідае астатняе развязанне VM нязменным.
Праверце лакатар, а не голы імя хоста. Пінг да імя дамена не даказвае амаль нічога, а запыт SRV для запісаў кантролераў дамена або вяртае чаканыя цэлі, або адразу няўдаецца:
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53Замяніце імя дамена і два адрасы значэннямі з канфігурацыі кіруемага дамена; лікі тут — прыклады. Калі запыт вяртае адказы іншай зоны, VM выкарыстоўвае рэзалвер, які не перанакіроўвае кіруемую прастору імёнаў, і ніякая колькасць паўторных спроб далучэння гэтага не зменіць.
Трымайце рабочую нагрузку па-за падсеткай, якую кіруемы дамен рэзервуе для сваіх службовых рэсурсаў, і трымайце порты каталога на прыватным шляху. Публічнае выкрыццё гэтых портаў — не скарот; гэта іншы дызайн з іншым профілем рызыкі.
Прыдатнасць уліковага запісу правяраецца раней за машыну
Уліковы запіс, які выконвае далучэнне, патрабуе дазволу ствараць аб’ект камп’ютара ў мэтавым кантэйнеры, і мусіць мець магчымасць аўтэнтыфікавацца ў кіруемым дамене. Хмарны ўліковы запіс, створаны да існавання кіруемага дамена, можа не мець матэрыялу, вытворнага ад пароля, які патрэбны дамену, а змена або скід пароля генеруюць яго нанова. Гэтая дэталь тлумачыць клас збояў далучэння, якія выглядаюць як няправільныя паролі, калі пароль правільны. Праверце ўліковыя даныя супраць дамена да адкрыцця акна абслугоўвання.
Сінхранізаваныя гібрыдныя ўліковыя запісы маюць свае перадумовы, якія бачны аб’ект карыстальніка сам па сабе не задавальняе. Быць у спісе каталога — не тое ж, што мець магчымасць атрымаць з яго білет, таму праверце ўліковы запіс да акна абслугоўвання, а не падчас яго.
Дэлегуйце права далучэння вузка. Даць кожнаму будучаму карыстальніку сервера членства ў адміністратарах дамена, каб адбылася адна рэгістрацыя, — гэта пастаянны дазвол дзеля часовай праблемы.
Само далучэнне — гэта адна каманда
Калі мадэль абраная, DNS адказвае, а ўліковы запіс прыдатны, аперацыя — звычайная аперацыя Windows. Запыт трымае пароль па-за скрыптамі і гісторыяй абалонкі:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThruКаманда не перазапускае машыну сама ў гэтай форме, таму перазапуск адбываецца па плане абслугоўвання і з даступным шляхам аднаўлення. Сервер, ужо далучаны да іншага дамена, патрабуе плана міграцыі, а не другога далучэння паверх першага.
Запішыце кантэйнер, у які трапіў аб’ект камп’ютара, і ўліковы запіс, які яго стварыў. Абодва важныя, калі машыну трэба далучыць нанова пасля перабудовы, і ні адзін з іх не відавочны з сервера пасля.
Што членства не дае
Членства ў дамене не робіць нікога лакальным адміністратарам і не дае доступу да аддаленага працоўнага стала ці агульных файлаў. Гэтыя правы наладжваюцца асобна, і ў кіруемым дамене яны застаюцца ў межах яго падтрымліванай адміністрацыйнай сферы.
Сеткавы шлях — гэта пастаянная залежнасць, а не крок налады. Калі прыватнае злучэнне знікае, сервер працягвае працаваць з кэшаванымі ўліковымі данымі, пакуль нешта не запатрабуе каталога, і тады збой прыйдзе ў журнал праграмы, а не побач з наладай, якая змянілася.
Кіраўніцтва Microsoft па далучэнні Windows Server пералічвае падтрымліваныя перадумовы для працэсу кіруемага дамена. Чытайце яго супраць трох рашэнняў вышэй і лічыце любое разыходжанне прычынай спыніцца, а не дэталлю, якую трэба абыйсці.