У меня есть автономный Windows Server 2003 с SQL Server 2005 и контроллер домена Windows Server 2003 Active Directory. Используя планы обслуживания / агент SQL Server, я пытаюсь записать дампы базы данных из автономного блока в общий ресурс на DC. Я знаю обычные правила доступа к удаленным общим ресурсам (например, я должен использовать учетную запись с соответствующими правами и т. Д.). Фактически, запись дампов на другой сервер, не являющийся DC, в том же домене, что и DC, работает нормально.
Я пытаюсь установить учетные данные для входа в учетную запись агента SQL Server на «домен \ имя пользователя» (или имя пользователя @ addomainname). Если я укажу имя пользователя в виде «домен \ имя пользователя», я получу (независимо от пароля) ошибку:
«Имя учетной записи недействительно или не существует, или пароль недействителен для указанного имени учетной записи».
Если я укажу имя пользователя в виде «user @ addomainname», я получаю ошибку (независимо от пароля):
«Указанный домен либо не существует, либо с ним невозможно связаться».
Я включил аудит отказов входа в систему на контроллере домена, и я не вижу сбоев в журнале, что говорит мне о том, что машина даже не пытается аутентифицироваться, а скорее терпит неудачу до этого.
Я знаю, что пользователи на серверах, не являющихся членами жестяная банка аутентифицироваться в общих ресурсах на DC, потому что выполнение интерактивный вход в систему (например, "net use * \ dcname \ c $ / user: username @ addomainname" или использование другой формы имени пользователя) работает нормально.
Приведенный выше пример относится к SQL Server, но применим к любой службе Windows.
Почему служба не может войти в систему с учетной записью домена, но интерактивный вход в систему (сопоставление дисков) с использованием той же учетной записи работает?
Благодаря поддержке Rackspace (размещающей эту конкретную конфигурацию) я теперь понимаю ситуацию.
Пример сопоставления дисков «net use * ...» и пример службы - это сравнение яблок с апельсинами. В случае сопоставления дисков происходит просто аутентификация. В случае службы я на самом деле пытаюсь запустить локальный процесс под учетными данными домена, что по определению невозможно, поскольку сервер не находится в домене. Не в домене = не может выполняться под учетными данными домена. Сопоставление дисков работает, потому что я не пытаюсь выполнить процесс как учетную запись домена - я просто передаю учетные данные.
Это ограничение применяется к любому типу процесса, независимо от того, интерактивный он или сервисный.
Можете ли вы получить доступ к общему ресурсу с SQL-сервера через сеть? Если так, я ничем не могу вам помочь. Если нет, это похоже на проблему с DNS с поиском контроллера домена для аутентификации. Попробуйте из командной строки
nslookup
set type=all
_ldap._tcp.dc._msdcs.Domain_Name