Это упрощение, и имена были изменены, чтобы защитить невиновных.
The assets:
Active Directory Domains
corp.lan
saas.lan
User accounts
user01@corp.lan
user02@corp.lan
Servers
dc.corp.lan (domain controller)
dc.saas.lan (domain controller)
server.saas.lan
Между доменами существует одностороннее доверие, поэтому учетные записи пользователей в corp.lan и вход на серверы в saas.lan
Нет брандмауэра между dc.corp.lan и dc.saas.lan
server.saas.lan находится в зоне с брандмауэром, и существует набор правил, позволяющих ему взаимодействовать с dc.saas.lan
Я могу войти в server.saas.lan с user01@corp.lan - но я не понимаю, как это работает. Если я смотрю журналы брандмауэра, я вижу кучу болтовни при входе между server.saas.lan и dc.saas.lan
Я также вижу кучу DROPPED болтовни между server.saas.lan и dc.corp.lan. Предположительно, это потому, что server.saas.lan пытается аутентифицировать user01@corp.lan, но не существует правила брандмауэра, разрешающего связь между этими хостами.
Однако user01@corp.lan может успешно войти на server.saas.lan. После входа в систему я могу «echo% logonserver%» и получить \ dc.corp.lan.
Итак .... Я немного запутался, как на самом деле аутентифицируется учетная запись. Обращается ли dc.saas.lan к dc.corp.lan после того, как server.saas.lan не может разговаривать с dc.corp.lan?
Просто пытаюсь понять, что нужно изменить / исправить / изменить.
Вы не даете нам достаточно подробностей, чтобы ответить на этот вопрос с уверенностью. Например, вы не предоставляете нам никакой информации о точном характере блокируемого трафика, какой это трафик, лес или внешнее доверие, какие порты разрешены между членами каждого домена, как именно вы пытаетесь для подключения к серверу (Удаленный рабочий стол? Сопоставление дисков?) и т. д. и т. д.
Я все равно приму удар. Предположим, я пытаюсь использовать клиент удаленного рабочего стола для подключения к серверу в другом лесу. Итак, мы знаем, что между клиентом и сервером должен быть разрешен хотя бы TCP-порт 3389.
(Для справки, Этот документ по сути, это библия того, как Active Directory использует Kerberos. ИМХО, одна из лучших статей TechNet в Интернете. Вот еще один чрезвычайно актуальная статья TechNet о доверии AD, которую вы можете добавить в закладки.)
Во время проверки подлинности с использованием Kerberos одним из последних шагов является то, что клиент отправляет свой билет службы и средство проверки подлинности непосредственно удаленной службе, к которой он пытается получить доступ. (KRB_AP_REQ, а затем необязательный KRB_AP_REP обратно от сервера к клиенту). Если этого не может произойти из-за блокировки портов, аутентификация Kerberos невозможна. Если я получаю от своего DC реферал TGS, который направляет меня на ваш DC, и я не могу напрямую запросить ваш DC, я не могу использовать Kerberos.
Возможно, это часть трафика, который, как вы видите, падает.
Итак, что происходит при сбое Kerberos? Клиент обычно возвращается к следующему провайдеру безопасности, например NTLM. Вы можете передать защищенные NTLM учетные данные на сервер прямо через тот же порт 3389. На этом этапе серверу просто нужно проверить ваши учетные данные. Пожалуйста, обратитесь к разделу «Обработка переходов NTLM» во второй статье, на которую я указал.
Обработка переходов NTLM
Если клиент использует NTLM для проверки подлинности, первоначальный запрос на проверку подлинности отправляется напрямую от клиента на сервер ресурсов в целевом домене. Этот сервер создает вызов, на который отвечает клиент. Затем сервер отправляет ответ пользователя контроллеру домена в домене учетной записи компьютера. Этот контроллер домена проверяет учетную запись пользователя по своей базе данных учетных записей безопасности. Если учетная запись не существует в базе данных, контроллер домена определяет, выполнять ли сквозную проверку подлинности, пересылать запрос или отклонять запрос, используя следующую логику:
Имеет ли текущий домен прямые доверительные отношения с доменом пользователя?
◦ Если да, контроллер домена отправляет учетные данные клиента контроллеру домена в домене пользователя для сквозной аутентификации.
◦ Если нет, переходите к следующему шагу.
Имеет ли текущий домен транзитивные доверительные отношения с доменом пользователя?
◦ Если да, передайте запрос аутентификации следующему домену в пути доверия. Этот контроллер домена повторяет процесс, проверяя учетные данные пользователя по своей базе данных учетных записей безопасности.
◦ Если нет, отправьте клиенту сообщение об отказе в входе в систему.
Итак, в конечном итоге, учитывая ограниченную информацию, которую вы нам предоставили, это процесс, свидетелем которого, как я полагаю, вы являетесь при аутентификации в службе в другом домене.