none
Каким образом можно настроить так, чтобы SQL Agent подключался к SQL Server с Kerberos аутентификацией ? RRS feed

  • Общие обсуждения

  • Каким образом можно настроить так, чтобы SQL Agent подключался к SQL Server с Kerberos аутентификацией ?

    • На SQL Server были отключены все протоколы, кроме TCP/IP.
    • SQL Server стартует под доменной учёткой, и для него прописаны SPN
    • Для SQL Agent была создана в домене отдельная учётная запись.

    Было попробовано:

    • http://www.ehow.com/how_7205044_register-_spn_-sql-server-agent.html
    • Подключение SQL Agent к SQL Server было настроено через Alias (на дополнительно открытый порт) в попытке каким-то образом создать для учётной записи SQL Agent корректный SPN.

    Но всё равно SQL Agent подключается к SQL Server по NTLM.

    SELECT sc.auth_scheme, es.host_name, es.login_name,
    
    sc.client_net_address, sc.local_tcp_port, sc.net_transport,
    
    sc.protocol_type, es.client_interface_name, es.program_name
    
    FROM [master].[sys].[dm_exec_sessions] es
    
    inner join [master].[sys].[dm_exec_connections] sc
    
    on es.session_id = sc.session_id
    
    WHERE es.program_name like 'SQLAgent%'
    
    
    
    
    P.S.
    Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)   Apr  2 2010 15:48:46
    Copyright (c) Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: ) (Hypervisor)
    21 декабря 2010 г. 8:48

Все ответы

  • Кто-нибудь может разъяснить разницу между пунктом 1 и пунктом 2
    в Authentication Defaults (Значения по умолчанию для проверки подлинности) ?
    Особенно с учётом примечания в этих пунктах...

    http://technet.microsoft.com/en-us/library/ms191153(SQL.100).aspx

    Authentication Defaults
    The following table describes the authentication defaults that are used based on SPN registration scenarios.

    http://technet.microsoft.com/ru-ru/library/ms191153(SQL.100).aspx

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

     

    • Объединено Yuriy Lenchenkov 28 декабря 2010 г. 8:23 подключение к SQL Server c kerberos аутентификацией
    22 декабря 2010 г. 14:32
  • А в чём, собственно вопрос?

    О каких пунктах речь? (в статьях я пунктов не увидел) Может Вы про перечисленные в таблице сценарии?

     ...в табличке представлены некоторые особенности аутентификации с использованием SPN, если нужно более подрбно, наверное, стоит поднять описание Кербероса...

    Может вот эта статья на примере поможет разъяснить, зачем вообще бывает нужно правильно создвать SPN: http://msmvps.com/blogs/gladchenko/archive/2007/08/24/1135194.aspx

     

    22 декабря 2010 г. 15:35
  • Вопрос: в чём разница (не считая Local System or NETWORK SERVICE):

    The SPN maps to the correct domain or built-in account. For example, Local System or NETWORK SERVICE.
    NoteNote
    Correct means that the account mapped by the registered SPN is the account that the SQL Server service is running under.

    The SPN is the correct domain or built-in account.
    NoteNote
    Correct means that the account mapped by the registered SPN is the account that the SQL Server service is running under.

    И там, и там correct domain account. Note - абсолютно одинаковые. А результат - разный:

    Local connections use NTLM, remote connections use Kerberos.
    или
    Local and remote connections use Kerberos.

    22 декабря 2010 г. 15:47
  • Вы хотите понять, чем отличяется мапинг на доменную или встроенную учётку от самой учётки?

    ...если вопрос в этом, то тут речь идёт о сопоставлении клиенского контекста. Например, если клиент использует SPN службы для выполнения неких действий на третьем компьютере, т.е. когда для этого нужно настроить делегирование. Если при этом упомянутый SPN мапистя на локального встроенного пользовалея (LOCALSYSTEM), то делегирования не случится, т.к. в этом случае не удастся задействовать Керберос.

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

    23 декабря 2010 г. 7:52
  • Извиняюсь за то, что может быть недостаточно ясно выразился вначале.

    В конечном итоге меня интересует как настроить SQL Agent, чтобы он подключался к локальному SQL Server с использованием Kerberos.

    Замечание: все подключения с других компьютеров на указанный SQL Server производятся с использованием Kerberos, а на самом сервере все протоколы запрещены, кроме tcp/ip.

    В ходе исследования выяснилось, что не только SQL Agent подключается к SQL Server с использованием NTLM, а вообще любое локальное подключение (ODBC, SQL Mgmt Studio, ...) производится именно с NTLM.

    После этого была найдена вышеприведённая статья в документации SQL Server, в которой есть две строки в вышеуказанной таблице. В них в том числе указано, что есть вариант настройки, когда локальные подключения к SQL Server выполняются по Kerberos.

    Но далее непонятно, как это сделать. Т.к. в другой строке вышеуказанной таблицы для варианта настойки, когда локальные подключения к SQL Server выполняются по NTLM указаны ТЕ ЖЕ САМЫЕ ТРЕБОВАНИЯ, что и для варианта, когда локальные подключения к SQL Server выполняются по Kerberos.

    У меня есть предположение, что локальные подключения выполняются с использованием Kerberos только в случае built-in учётных записей домена. Но, возможно, оно неверное. Хотелось уточнить у знающих людей.

    P.S.
    И если предположение неверное, то выяснить, как настроить все сервисы SQL Server'а и задать необходимые SPN, чтобы локальные подключения производились с использованием Kerberos.

    23 декабря 2010 г. 8:25
  • а не для сервера ли надо spn создавать?

    http://blogs.msdn.com/b/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx

     


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    23 декабря 2010 г. 9:39
  • Для сервера SPN созданы.
    Все удалённые подключения используют Kerberos.

    Из вышеприведённой статьи из пункта III ничего не подходит вроде:

    III. When are Kerbers and NTLM applied when connect to SQL Server 2005.
    Under condition that you are using Integrated Security or trusted connection which use windows authentication.
    1) Kerberos is used when making remote connection over TCP/IP if SPN presents.
    2) Kerberos is used when making local tcp connection on XP if SPN presents.
    3) NTLM is used when making local connection on WIN 2K3.
    4) NTLM is used over NP connection.
    5) NTLM is used over TCP connection if not found SPN.

    у меня получается NTLM is used when making local connection on WIN2K8R2.

     

    23 декабря 2010 г. 10:12
  • напишите какой командой регистрировали spn для сервера, пожалуйста
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    23 декабря 2010 г. 10:42
  • C:\>setspn -L mydom\sqlacc

    Registered ServicePrincipalNames for CN=sqlacc,OU=Services,OU=Service Accounts,DC=mydom,DC=local:

        MSSQLSvc/mydom-sqlsrv:inst
        MSSQLSvc/mydom-sqlsrv:1433
        MSSQLSvc/mydom-sqlsrv.mydom.local:inst
        MSSQLSvc/mydom-sqlsrv.mydom.local:1433

     

    23 декабря 2010 г. 10:49
  • Очень любопытно, а зачем такое могло понадобиться?

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

    23 декабря 2010 г. 11:26
  • Я, наверное, чего-то не понимаю.

    SQL Agent стартует из-под доменной учётной записи. Обращений к AD не происходит ?

     

    23 декабря 2010 г. 11:48
  • Во время запуска будут проверены в AD права, пароль и т.п. Т.ч. происходит.

    23 декабря 2010 г. 13:37
  • Так Kerberos или NTLM именно в этот момент и работают.

    А также, когда SQL Server будет проверять: дать доступ или нет.

     

    23 декабря 2010 г. 14:27
  • SQL Server будет аутентифицировать и авторизовать логин, когда шаг задания или сам агент обратиться к нему с запросом, который будет выполнен в одном из четырёх возможных контекстов безопастности: стартующей агента учётки, учётки прокси, логина задания или логина шага.

    23 декабря 2010 г. 14:47
  • inst - подключение не к default instance?

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    23 декабря 2010 г. 14:55
  • inst - именованный

    IP адрес - статический

     

    23 декабря 2010 г. 14:59
  • н-да, не подумал об этом.

    но тем более, если на SQL сервере выставлена только Windows аутентификация, то всё это Domain Accounts и желательно было бы, чтобы вся эта аутентификация проходила с использованием Kerberos.

    23 декабря 2010 г. 15:05
  • а в users&computers у учетки, от имени которой стартует служба sql server на вкладке delegation какие настройки?

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    23 декабря 2010 г. 15:14
  • Trust this user for delegation to any service (Kerberos only)
    23 декабря 2010 г. 15:19
  • н-да, не подумал об этом.

    но тем более, если на SQL сервере выставлена только Windows аутентификация, то всё это Domain Accounts и желательно было бы, чтобы вся эта аутентификация проходила с использованием Kerberos.


    Вы так и не пояснили, откуда взялось такое желание? :)

    ИМХО, тут гарантия подлинности Кербероса не нужна, поскольку клиент и так уже имеет доступ к локальным ресурсам и достаточно разграничений контекста операционными средствами. Нужно только разрешить шаредмемори.

    24 декабря 2010 г. 14:30
  •  Вы так и не пояснили, откуда взялось такое желание? :)

    А мне так никто и не ответил по поводу документации,
    в которой, при двух одинаковых условиях, два разных результата. :)

    Насчёт достаточности шаредмемори - непонятно.

    Агент стартует - работает аутентификация.

    Как Вы напомнили:
    - стартует JOB под другой учётной записью - работает аутентификация,
    - стартует Step под другой учётной записью - работает аутентификация,
    - прокси - иже с ними.

    И всё это, кроме постоянно работающего Агента, многократно.

    И ещё, ведь не только Агент, а вообще все локальные подключения идут по NTLM.

    И Microsoft рекомендует Kerberos:
    http://technet.microsoft.com/ru-ru/library/dd546901.aspx

    P.S.
    Хочется один раз разобраться с проблемой и более к ней не возвращаться.
    Завтра, будет время, попробую kerbtray запустить и посмотреть, из-за чего все локальные подключения к SQL сваливаются на NTLM.
    В любом случае, для игнорирования какой-то проблемы требуется понимание из-за чего она происходит...

    24 декабря 2010 г. 22:20
  • Завтра, будет время, попробую kerbtray запустить и посмотреть, из-за чего все локальные подключения к SQL сваливаются на NTLM.
    В любом случае, для игнорирования какой-то проблемы требуется понимание из-за чего она происходит...

    Трассировка и аудит кербероса - это правильный подход. Расскажите потом, что будет среди ошибок?
    28 декабря 2010 г. 9:44
  • В общем, трассировка и аудит пока ни к чему не привели.

    Хотя встречаются ошибки:

     Error Code: 0xd KDC_ERR_BADOPTION
     Extended Error: 0xc00000bb KLIN(0)
     Error Text:
     File: 9
     Line: efb
     Error Data is in record data.

     Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
     Extended Error:
     Error Text:
     File: e
     Line: 9fe
     Error Data is in record data.

    Буду думать, что с ними делать.
    Смотрю "Troubleshooting Kerberos Errors" (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7DFEB015-6043-47DB-8238-DC7AF89C93F1&displaylang=en).

    KDC_ERR_BADOPTION
    Confirm the cause by verifying the expiration time on the TGTConfirm the cause by verifying the expiration time on the TGT

    KeyExpirationTime: 1/1/1601 3:00:00 - вроде как это допустимо ?

    P.S.
    Зато удалось локально подключиться к SQL Server с использованием Kerberos через ODBC.
    С использованием новой возможности указания UPN вместо SPN в настройках ODBC:
    username@FQDN из-под которого стартует SQL Server (http://msdn.microsoft.com/en-us/library/ee191523(SQL.100).aspx)

    Правда непонятно, можно ли настроить SQL Agent для работы через такое соединение... Так как он сам строит ODBC... И возможность указать Alias здесь не помогает...

    30 декабря 2010 г. 14:04