Доверительные отношения между доменами 2003

Домены и доверительные отношения

Домен занимает центральное место в Active Directory.

Под доменом понимается совокупность компьютеров, характеризующихся наличием общей базы учетных записей пользователей и единой политикой безопасности.

Таким образом, доменом называется отдельная область безопасности в компьютерной сети Windows, использующей технологию NT.

Служба каталогов Active Directory может охватывать один или нескольких доменов. На автономной рабочей станции доменом является сам компьютер. С физической точки зрения домен может включать в себя компьютеры, расположенные в разных местах. В каждом домене действует своя политика безопасности и свои отношения безопасности с другими доменами.

Если несколько доменов связаны доверительными отношениями и имеют одни и те же схему, конфигурацию и глобальный каталог, мы имеем дерево доменов. Несколько деревьев доменов могут быть объединены в лес.

Дерево доменов (дерево) состоит из нескольких доменов, имеющих общие схему и конфигурацию и тем самым образующих общее пространство имен. Домены одного дерева также связаны между собой доверительными отношениями. Служба каталогов Active Directory представляет собой множество, состоящее из одного или нескольких деревьев.

Деревья можно рассматривать с двух точек зрения: с позиции доверительных отношений между доменами или как пространство имен дерева доменов.

Дерево доменов можно представить в виде индивидуальных доменов и существующих между ними доверительных отношений.

Операционная система Windows 2000/2003 устанавливает доверительные отношения между доменами на основе протокола безопасности Kerberos 5.

Доверительные отношения по протоколу Kerberos транзитивны: если домен A доверяет домену B, а домен B доверяет домену C, то домен A доверяет домену C. Доверяющий домен будет доверять процедуре аутентификации на доверенном домене, т. е. учетные записи доверенного домена можно использовать на доверяющем домене (рис. 3.8). Значит, пользователям доверенного домена могут быть даны ресурсы доверяющего домена.

Рис 3.8. Дерево доменов, рассматриваемое в терминах доверительных отношений

Можно представить дерево доменов на основе пространства имен (рис. 3.9).

Рис. 3.9. Представление дерева доменов в виде пространства имен

Лесом называется набор, состоящий из одного или нескольких деревьев, которые не образуют непрерывного пространства имен. Все деревья леса имеют одни и те же схему, конфигурацию и глобальный каталог. Все деревья леса связаны доверительными отношениями посредством транзитивных доверительных отношений по протоколу Kerberos.

Лес, в отличие от дерева, не должен иметь отличающее его имя. Лес существует как набор объектов перекрестных ссылок и доверительных отношений по протоколу Kerberos, известных деревьям, составляющим этот лес (рис. 3.10).

Рис. 3.10. Лес, содержащий более одного дерева

Деревья леса образуют иерархию доверия по протоколу Kerberos; имя дерева, находящегося в корне дерева доверия, может быть использовано для ссылки на указанный лес.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Восстанавливаем доверительные отношения в домене

Восстанавливаем доверительные отношения в домене

• Автор: Уваров А.С.
• 28.02.2015

С ошибкой «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» время от времени приходится сталкиваться каждому системному администратору. Но не каждый понимает причины и механизмы процессов, приводящие к ее возникновению. Потому что без понимания смысла происходящих событий невозможно осмысленное администрирование, которое подменяется бездумным выполнением инструкций.

Учетные записи компьютеров, также, как и учетные записи пользователей, являются участниками безопасности домена. Каждому участнику безопасности автоматически присваивается идентификатор безопасности (SID) на уровне которого осуществляется доступ к ресурсам домена.

Перед тем как предоставить учетной записи доступ к домену необходимо проверить ее подлинность. Каждый участник безопасности должен иметь свою учетную запись и пароль, учетная запись компьютера не исключение. При присоединении компьютера к Active Directory для него создается учетная запись типа «Компьютер» и устанавливается пароль. Доверие на этом уровне обеспечивается тем, что данная операция производится администратором домена или иным пользователем, имеющим для этого явные полномочия.

Впоследствии при каждом входе в домен компьютер устанавливает защищенный канал с контроллером домена и сообщает ему свои учетные данные. Таким образом между компьютером и доменом устанавливаются доверительные отношения и дальнейшее взаимодействие происходит согласно установленных администратором политик безопасности и прав доступа.

Пароль учетной записи компьютера действует 30 дней и впоследствии автоматически изменяется. При этом важно понимать, что смену пароля инициирует компьютер. Это происходит аналогично процессу смены пароля пользователя. Обнаружив, что текущий пароль просрочен, компьютер при очередном входе в домен его заменит. Поэтому, даже если вы не включали компьютер несколько месяцев, доверительные отношения в домене сохранятся, а пароль будет заменен при первом входе после длительного перерыва.

Доверительные отношения нарушаются в том случае, если компьютер пытается аутентифицироваться в домене с недействительным паролем. Как такое может произойти? Самый простой способ — это откатить состояние компьютера, например, штатной утилитой восстановления системы. Такой же эффект может быть достигнут при восстановлении из образа, снапшота (для виртуальных машин) и т.п.

Еще один вариант — это изменение учетной записи другим компьютером с таким же именем. Ситуация довольно редкая, но иногда случается, например, когда сотруднику поменяли ПК с сохранением имени, выведя из домена старый, а потом снова ввели его в домен забыв переименовать. В этом случае старый ПК при повторном вводе в домен сменит пароль ученой записи компьютера и новый ПК уже не сможет войти, так как не сможет установить доверительные отношения.

Какие действия следует предпринять, столкнувшись с данной ошибкой? Прежде всего установить причину нарушения доверительных отношений. Если это был откат, то кем, когда и каким образом он был произведен, если пароль был сменен другим компьютером, то опять-таки надо выяснить, когда и при каких обстоятельствах это произошло.

Простой пример: старый компьютер переименовали и отдали в другой отдел, после чего произошел сбой, и он автоматически откатился на последнюю контрольную точку. После чего данный ПК попытается аутентифицироваться в домене под старым именем и закономерно получит ошибку установления доверительных отношений. Правильными действиями в этом случае будет переименовать компьютер как он должен называться, создать новую контрольную точку и удалить старые.

И только убедившись, что нарушение доверительных отношений было вызвано объективно необходимыми действиями и именно для этого компьютера можно приступать к восстановлению доверия. Сделать это можно несколькими способами.

Пользователи и компьютеры Active Directory

Это самый простой, но не самый быстрый и удобный способ. Открываем на любом контроллере домена оснастку Пользователи и компьютеры Active Directory, находим необходимую учетную запись компьютера и, щелкнув правой кнопкой мыши, выбираем Переустановить учетную запись.

Затем входим на потерявшем доверительные отношения компьютере под локальным администратором и выводим машину из домена.

Затем вводим ее обратно, перезагрузку между этими двумя действиями можно пропустить. После повторного ввода в домен перезагружаемся и входим под доменной учетной записью. Пароль компьютера будет изменен при повторном включении компьютера в домен.

Недостаток этого способа, что машину требуется выводить из домена, а также необходимость двух (одной) перезагрузки.

Утилита Netdom

Данная утилита входит в состав Windows Server начиная с редакции 2008, на пользовательские ПК ее можно установить из состава пакета RSAT (Средства удаленного администрирования сервера). Для ее использования войдите на целевой системе локальным администратором и выполните команду:

Разберем опции команды:

• Server — имя любого доменного контроллера
• UserD — имя учетной записи администратора домена
• PasswordD — пароль администратора домена

После успешного выполнения команды перезагрузка не требуется, просто выйдите из локальной ученой записи и войдите в доменный аккаунт.

Командлет PowerShell 3.0

В отличие от утилиты Netdom, PowerShell 3.0 входит в состав системы начиная с Windows 8 / Server 2012, для более старых систем его можно установить вручную, поддерживаются Windows 7, Server 2008 и Server 2008 R2. В качестве зависимости требуется Net Framework не ниже 4.0.

Точно также войдите на системе, для которой нужно восстановить доверительные отношения, локальным администратором, запустите консоль PowerShell и выполните команду:

• Server — имя любого контроллера домена
• Credential — имя домена / учетной записи администратора домена

При выполнении этой команды появится окно авторизации в котором вы должны будете ввести пароль для указанной вами учетной записи администратора домена.

Командлет не выводит никаких сообщений при удачном завершении, поэтому просто смените учетную запись, перезагрузка не требуется.

Как видим, восстановить доверительные отношения в домене довольно просто, главное — правильно установить причину возникновения данной проблемы, так как в разных случаях потребуются разные методы. Поэтому мы не устаем повторять: при возникновении любой неполадки сначала нужно выявить причину, а только потом принимать меры к ее исправлению, вместо того чтобы бездумно повторять первую найденную в сети инструкцию.

Доверительные отношения между доменами 2003

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Во, у меня еще хуже!
Умные люди, пдскажите кому-нибудь удалось установить доверительные отношения между доменами win2003 server ent и win nt4.

1) Есть 2 домена: домен -> DOM0 -> контроллер DC0 -> windows NT4 SP6
домен -> DOM1 -> контроллер DC1 -> windows server 2003 sp1
Обе системы поставлены с нуля, никаких файрволов и прочего софта.

2) на обоих котроллерах подняты WINS(не партнеры по репликации),
а в файлах lmhosts содержится:
# LMHOSTS
# «123456789012345*7890»
10.157.3.90 DC0 #PRE #DOM:DOM0
10.157.3.90 «DOM0 x1b» #PRE
10.157.1.91 DC1 #PRE #DOM:DOM1
10.157.1.91 «DOM1 x1b» #PRE

пробовал и такие строчки добавлять, в файл
10.157.3.90 «DOM0 x1C» #PRE
10.157.1.91 «DOM1 x1C» #PRE

пробовал и статические записи в WINS-ах,пробовал WINS-ы отключать

3) nbtstat -c на сервере NT4
Name Type Host Address Life [sec]
————————————————————
DC1 UNIQUE 10.157.1.91 -1
DC1 UNIQUE 10.157.1.91 -1
DC1 UNIQUE 10.157.1.91 -1
DOM1 GROUP 10.157.1.91 -1
DOM1 UNIQUE 10.157.1.91 -1

nbtstat -c на сервере win2003
Name Type Host Address Life [sec]
————————————————————
DC0 UNIQUE 10.157.3.90 -1
DC0 UNIQUE 10.157.3.90 -1
DC0 UNIQUE 10.157.3.90 -1
DOM0 GROUP 10.157.3.90 -1
DOM0 UNIQUE 10.157.3.90 -1

4) на обоих конторллерах HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLSA
RestrictAnonymous = 0

5) ПРОБЛЕМА! При попытке установить доверительные отношения между доменами
контроллер 2003 кричит:
«The trust relationship cannot be created because the following error occurred:
The Local Security Authority is unable to obtain an RPC connection to the domain controller DCO.
Please check that the name can be resolved and that the server is available.»

ГДЕ ГРАБЛИ. Я задолбался уже.
Причем между этим-же NT4 доменом и win2000 SP4 доменами,
а также другими NT4 доменами все с доверием OK!
В логах на обеих контроллерах тоже все чисто.

Что я делаю не так.

http://support.microsoft.com/kb/325874/ru#kb1 — не предлагать!

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору служба RPC пашет на w2k3 ? также проверь телнетом на w2k3 135 порт на машину NT4 , возможно еще и в политиках безопасности w2k3 что-то по дефолту задисаблено, в том числе RPC , прогони dcdiag /v и netdaig /v на w2k3

Добавлено:
проверь на w2k3 утилитой RPCPING :
rpcping -s 10.157.3.90

Добавлено:
по порядку
1. служба Remote Procedure Call (RPC) — на 2003 — запущена
служба Remote Procedure Call (RPC) Locator — на 2003 остановлена. запустил.

2. «telnet DC1 135» т.е. с НТ4 на 2003
дает пустой экран с мерцающим курсором. плохо это или хорошо?

3. rpcping.exe -s 10.157.3.90
Completed 1 calls in 31 ms
32 T/S or 31.000 ms/T
т.е. вроде как ок.

4.
4a. netdiag /v везде сплошной PASS, кроме Messenger — так он отключен по умолчанию в 2003sp1
NetBT name test. . . . . . : Passed
NetBT_Tcpip_ <561D0385-675A-486D-A628-CA61DA22FD52>
DC1 UNIQUE REGISTERED
DC1 UNIQUE REGISTERED
DOM1 GROUP REGISTERED
DOM1 GROUP REGISTERED
DOM1 GROUP REGISTERED
DOM1 UNIQUE REGISTERED
..__MSBROWSE__. GROUP REGISTERED
DOM1 UNIQUE REGISTERED
[WARNING] At least one of the ‘WorkStation Service’, ‘Messenger Service’, ‘WINS’ names is missing.
NetBios Resolution : Enabled
Netbios Remote Cache Table
Name Type HostAddress Life [sec]
—————————————————————
DC0 UNIQUE 10.157.3.90 -1
DC0 UNIQUE 10.157.3.90 -1
DC0 UNIQUE 10.157.3.90 -1
DOM3 GROUP 10.157.1.91 582
DOM0 GROUP 10.157.3.90 -1
DOM0 UNIQUE 10.157.3.90 -1
WINS service test. . . . . : Passed
Sending name query to primary WINS server 10.157.1.91 — Passed
The test was successful. At least one WINS server was found.
IPX test : IPX is not installed on this machine.

4b. dcdiag /v везде сплошной PASS.
Domain Controller Diagnosis
Performing initial setup:
* Verifying that the local machine dc1, is a DC.
* Connecting to directory service on server dc1.
* Collecting site info.
* Identifying all servers.
* Identifying all NC cross-refs.
* Found 1 DC(s). Testing 1 of them.
Done gathering initial info.

Doing initial required tests

Testing server: Default-First-Site-Namedc1
Starting test: Connectivity
* Active Directory LDAP Services Check
* Active Directory RPC Services Check
. dc1 passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Namedc1
Starting test: Replications
* Replications Check
* Replication Latency Check
* Replication Site Latency Check
. dc1 passed test Replications
Test omitted by user request: Topology
Test omitted by user request: CutoffServers
Starting test: NCSecDesc
* Security Permissions check for all NC’s on DC dc1.
* Security Permissions Check for
DC=ForestDnsZones,DC=dom1,DC=ru
(NDNC,Version 2)
* Security Permissions Check for
DC=DomainDnsZones,DC=dom1,DC=ru
(NDNC,Version 2)
* Security Permissions Check for
CN=Schema,CN=Configuration,DC=dom1,DC=ru
(Schema,Version 2)
* Security Permissions Check for
CN=Configuration,DC=dom1,DC=ru
(Configuration,Version 2)
* Security Permissions Check for
DC=dom1,DC=ru
(Domain,Version 2)
. dc1 passed test NCSecDesc
Starting test: NetLogons
* Network Logons Privileges Check
Verified share \dc1netlogon
Verified share \dc1sysvol
. dc1 passed test NetLogons
Starting test: Advertising
The DC dc1 is advertising itself as a DC and having a DS.
The DC dc1 is advertising as an LDAP server
The DC dc1 is advertising as having a writeable directory
The DC dc1 is advertising as a Key Distribution Center
The DC dc1 is advertising as a time server
The DS dc1 is advertising as a GC.
. dc1 passed test Advertising
Starting test: KnowsOfRoleHolders
Role Schema Owner = CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru
Role Domain Owner = CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru
Role PDC Owner = CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru
Role Rid Owner = CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru
Role Infrastructure Update Owner = CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru
. dc1 passed test KnowsOfRoleHolders
Starting test: RidManager
* Available RID Pool for the Domain is 1604 to 1073741823
* dc1.dom1.net is the RID Master
* DsBind with RID Master was successful
* rIDAllocationPool is 1104 to 1603
* rIDPreviousAllocationPool is 1104 to 1603
* rIDNextRID: 1108
. dc1 passed test RidManager
Starting test: MachineAccount
Checking machine account for DC dc1 on DC dc1.
* SPN found :LDAP/dc1.dom1.net/dom1.net
* SPN found :LDAP/dc1.dom1.net
* SPN found :LDAP/dc1
* SPN found :LDAP/dc1.dom1.net/dom1
* SPN found :LDAP/e29783f4-8911-4e5f-ba45-6100f4ef3f2e._msdcs.dom1.net
* SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/e29783f4-8911-4e5f-ba45-6100f4ef3f2e/dom1.net
* SPN found :HOST/dc1.dom1.net/dom1.net
* SPN found :HOST/dc1.dom1.net
* SPN found :HOST/dc1
* SPN found :HOST/dc1.dom1.net/dom1
* SPN found :GC/dc1.dom1.net/dom1.net
. dc1 passed test MachineAccount
Starting test: Services
* Checking Service: Dnscache
* Checking Service: NtFrs
* Checking Service: IsmServ
* Checking Service: kdc
* Checking Service: SamSs
* Checking Service: LanmanServer
* Checking Service: LanmanWorkstation
* Checking Service: RpcSs
* Checking Service: w32time
* Checking Service: NETLOGON
. dc1 passed test Services
Test omitted by user request: OutboundSecureChannels
Starting test: ObjectsReplicated
dc1 is in domain DC=dom1,DC=ru
Checking for CN=dc1,OU=Domain Controllers,DC=dom1,DC=ru in domain DC=dom1,DC=ru on 1 servers
Object is up-to-date on all servers.
Checking for CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru in domain CN=Configuration,DC=dom1,DC=ru on 1 servers
Object is up-to-date on all servers.
. dc1 passed test ObjectsReplicated
Starting test: frssysvol
* The File Replication Service SYSVOL ready test
File Replication Service’s SYSVOL is ready
. dc1 passed test frssysvol
Starting test: frsevent
* The File Replication Service Event log test
. dc1 passed test frsevent
Starting test: kccevent
* The KCC Event log test
Found no KCC errors in Directory Service Event log in the last 15 minutes.
. dc1 passed test kccevent
Starting test: systemlog
* The System Event log test
Found no errors in System Event log in the last 60 minutes.
. dc1 passed test systemlog
Test omitted by user request: VerifyReplicas
Starting test: VerifyReferences
The system object reference (serverReference)
CN=dc1,OU=Domain Controllers,DC=dom1,DC=ru and backlink on
CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru
are correct.
The system object reference (frsComputerReferenceBL)
CN=dc1,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=dom1,DC=ru
and backlink on CN=dc1,OU=Domain Controllers,DC=dom1,DC=ru are
correct.
The system object reference (serverReferenceBL)
CN=dc1,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=dom1,DC=ru
and backlink on
CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dom1,DC=ru
are correct.
. dc1 passed test VerifyReferences
Test omitted by user request: VerifyEnterpriseReferences
Test omitted by user request: CheckSecurityError

Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
. ForestDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. ForestDnsZones passed test CheckSDRefDom

Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
. DomainDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. DomainDnsZones passed test CheckSDRefDom

Running partition tests on : Schema
Starting test: CrossRefValidation
. Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
. Schema passed test CheckSDRefDom

Running partition tests on : Configuration
Starting test: CrossRefValidation
. Configuration passed test CrossRefValidation
Starting test: CheckSDRefDom
. Configuration passed test CheckSDRefDom

Running partition tests on : dom1
Starting test: CrossRefValidation
. dom1 passed test CrossRefValidation
Starting test: CheckSDRefDom
. dom1 passed test CheckSDRefDom

Running enterprise tests on : dom1.net
Starting test: Intersite
Skipping site Default-First-Site-Name, this site is outside the scope
provided by the command line arguments provided.
. dom1.net passed test Intersite
Starting test: FsmoCheck
GC Name: \dc1.dom1.net
Locator Flags: 0xe00003fd
PDC Name: \dc1.dom1.net
Locator Flags: 0xe00003fd
Time Server Name: \dc1.dom1.net
Locator Flags: 0xe00003fd
Preferred Time Server Name: \dc1.dom1.net
Locator Flags: 0xe00003fd
KDC Name: \dc1.dom1.net
Locator Flags: 0xe00003fd
. dom1.net passed test FsmoCheck
Test omitted by user request: DNS
Test omitted by user request: DNS

Доверительные отношения между доменами и firewall

Я недавно интересовался настройкой доверительных отношений между доменами или лесами. В случае туннеля все несколько проще, в остальных случаях использование файрволла обязательно, а для этого нужно знать что открывать.

Чтобы межсетевой экран не препятствовал установлению безопасных каналов и доверительных отношений между доменами, на нем должны быть открыты перечисленные ниже порты. Поскольку по обе стороны межсетевого экрана могут находиться компьютеры, одновременно являющиеся как клиентом, так и сервером, необходимо, чтобы соответствующие порты были открыты в обе стороны.

Windows NT

Windows 2003 и Windows 2000 Server

Если домен Windows 2000 работает в смешанном режиме и в домене присутствуют контроллеры домена Windows NT или клиентские компьютеры, работающие под управлением устаревших версий операционных систем или если у этого домена установлены доверительные отношения с доменом Windows Server 2003 или Windows 2000 Server, расположенным в другом лесу, то в дополнение к перечисленным ниже портам следует открыть порты, указанные в предыдущей таблице.

Windows Server 2008/Windows Server 2008 R2

Если домен Windows 2008 работает в смешанном режиме и в домене присутствуют контроллеры домена Windows Server 2003 или клиентские компьютеры, работающие под управлением устаревших версий операционных систем, то динамический диапазон портов по умолчанию будет с 1025 по 5000. Для Windows Server 2008 и Windows Server 2008 R2, в соответствии с рекомендациями Internet Assigned Numbers Authority (IANA), был увеличен стартовый диапазон используемых портов. Новый диапазон теперь с 49152 по 65535. Следовательно, нужно увеличить диапазон портов RPC на своих файрволлах.

Чтобы служба каталогов Active Directory надлежащим образом работала в сети, содержащей межсетевые экраны, они должны пропускать пакеты протокола ICMP (Internet Control Message Protocol) от клиентских компьютеров к контроллерам домена. Это необходимо для получения клиентами сведений групповой политики. С помощью протокола ICMP определяется, является ли подключение быстрым или медленным. Протокол ICMP – это стандартный протокол, используемый службой каталогов Active Directory для определения максимального размера передаваемого блока данных (MTU) и определения доступности сервера, с которого должна загружаться групповая политика.
Чтобы свести к минимуму объем данных, передаваемых по протоколу ICMP, создайте на межсетевом экране правила, аналогичные приведенному ниже.

В отличие от протоколов, принадлежащих уровням TCP и UDP, в протоколе ICMP отсутствует номер порта, поскольку протокол ICMP расположен на уровне IP.

По умолчанию DNS-серверы под управлением Windows Server 2003 и Windows 2000 Server используют динамические номера портов при отправке запросов другим DNS-серверам. Чтобы изменить это поведение, необходимо изменить параметр реестра, описанный в следующей статье базы знаний Майкрософт:

260186 (http://support.microsoft.com/kb/260186/ ) Параметр реестра SendPort работает ненадлежащим образом

Подробнее о настройке службы каталогов Active Directory и брандмауэра можно прочитать в документе White Paper Майкрософт:

Кроме того, для установки доверительных отношений можно использовать туннель, созданный с использованием протокола PPTP (Point-to-Point Tunneling Protocol). Это позволит уменьшить число портов, которые должны быть открыты на межсетевом экране. Чтобы компьютеры могли создать туннель PPTP, на межсетевом экране должны быть открыты следующие порты:

Необходимо также разрешить прохождение пакетов протокола IP с полем типа протокола, равным 47 (GRE).

Примечание. Windows 2000 и Windows NT 4.0 по-разному ведут себя при предоставлении пользователю из доверенного домена прав доступа к ресурсам доверяющего домена. Если компьютеру не удается получить список пользователей удаленного домена, выполняются следующие действия.

Компьютер под управлением Windows NT 4.0 пытается выполнить разрешение имен, указанных вручную. Для этого он обращается к основному контроллеру удаленного домена пользователя. При этом используется порт 138 протокола UDP. Если выполнить данное подключение не удается, Windows NT 4.0 обращается к основному контроллеру своего домена и пытается выполнить разрешение имен.

Иллюстрированный самоучитель по Microsoft Windows 2003

Доверительные отношения

Доверительные отношения (trusts) представляют собой связь, устанавливаемую между доменами, позволяющую пользователям одного домена аутентифицироваться контроллером другого домена. Наличие механизма доверительных отношений позволяет организовывать совокупность доменов в некоторую структуру. В этой структуре домены связываются между собой определенным образом отношениями доверия.

Доверительные отношения реализуются в рамках механизма аутентификации. Суть доверительных отношений между двумя доменами сводится к тому, что доверяющий домен (trusting domain) доверяет процесс аутентификации доверенному домену (trusted domain). Пользователь, аутентифицированный доверенным доменом, может получить доступ к ресурсам в доверяющем домене.

Механизм аутентификации NTLM, реализованный в рамках архитектуры Windows NT, допускает создание только односторонних доверительных отношений. Если администратору было необходимо установить между доменами отношения взаимного доверия, он должен был создать доверительные отношения в обе стороны.

Служба каталога Active Directory допускает создание как односторонних, так и двусторонних доверительных отношений. Так же как и в случае Windows NT, односторонние доверительные отношения реализуются посредством механизма аутентификации NTLM. Двусторонние доверительные отношения строятся на основе протокола аутентификации Kerberos v5 и обладают свойством транзитивности.

Транзитивность доверительных отношений предполагает сквозную аутентификацию пользователей в цепочке доменов, связанных между собой подобными отношениями. Например, если домен А доверяет домену В, а домен В доверяет домену С, то между доменами А и С автоматически устанавливаются доверительные отношения (эти отношения неявные). Односторонние доверительные отношения NTLM не обладают свойствами транзитивности. Для создания отношений полного доверия между пятью доменами необходимо будет установить двадцать односторонних доверительных отношений. Аналогичного результата можно добиться при помощи всего лишь четырех двусторонних транзитивных доверительных отношений.

Для использования доверительных отношений не имеет значения, какой механизм аутентификации используется клиентом. Даже если клиент не поддерживает протокол Kerberos, он может быть аутентифицирован через двусторонние доверительные отношения.

Архитектура Windows Server 2003 позволяет использовать доверительные транзитивные отношения как для соединения доменов в пределах одного леса, так и для соединения разных лесов доменов. Кроме того, могут быть установлены доверительные отношения между различными областями Кегberos (Kerberos realms).

Все поддерживаемые типы доверительных отношений перечислены в табл. 18.1.

Таблица 18.1. Доверительные отношения, поддерживаемые доменами на базе Windows Server 2003.