Kdc has no support for encryption type while getting initial credentials как исправить ошибку

Fixes an issue in which user accounts that use DES encryption types for Kerberos cannot be authenticated in a Windows Server 2003 domain. This problem occurs after a Windows Server 2008 R2 domain controller joins the domain.

Windows Server 2008 R2 Datacenter Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Standard More…Less

Symptoms

Consider the following scenario:

  • A user account is created in a Windows Server 2003 domain.

  • All domain controllers in this domain are running Windows Server 2003.

  • The user account is configured to use Data Encryption Standard (DES) encryption types for Kerberos authentication.

  • A computer that is running Windows Server 2008 R2 joins the domain.

  • Active Directory is installed on the member server.

In this scenario, the user account cannot log on to the domain immediately after the Windows Server 2008 R2 domain controller starts. You may also receive the following error message:

KDC has no support for encryption type while getting initial credentials.

Additionally, the following events are logged in the System log on the domain controller that is running Windows Server 2008 R2:

Log Name: System
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Date: date
Event ID: 14
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computer_name
Description:
While processing an AS request for target service krbtgt, the account name did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 16 1 11 10 15 12 13. The accounts available etypes : 23 -133 -128. Changing or resetting the password of user_name will generate a proper key.

Log Name: System
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Date: date
Event ID: 16
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computer_name
Description:
While processing a TGS request for the target server server_name, the account account_name did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 9). The requested etypes were 3 1. The accounts available etypes were 23 -133 -128. Changing or resetting the password of account_name will generate a proper key.

Cause

This problem occurs because different data structures are used to save encryption type information about the user account on Windows Server 2003 domain controllers and on Windows Server 2008 R2 domain controllers.

When a user account is created on a Windows Server 2003 domain controller, the encryption type information is saved in a data structure. Then, this information is copied to Windows Server 2008 R2 domain controllers by using AD replication.

Note This problem also occurs when the password of a user account is reset.

When a Windows Server 2008 R2 domain controller authenticates the user account, the domain controller reads this encryption type information from the data structure that is used by the Windows Server 2003 domain controller. It should then copy this encryption type information to a different data structure. However, the information is not copied as expected. Therefore, authentication fails.

Resolution

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

The following list contains prerequisites for the hotfix:

  • You must have Windows Server 2008 R2 installed.

  • You must have the Active Directory Domain Service role service installed.

Installation note

Install this hotfix on all domain controllers that run Windows Server 2008 R2 in a Windows Server 2003 domain. This hotfix should not be applied to the Windows Server 2003 servers that are in the domain.

Registry information

To use the hotfix in this package, you do not have to make any changes to the registry.

Restart information

You may have to restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The English (United States) version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows Server 2008 R2 file information note

  • The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the «Additional file information for Windows Server 2008 R2» section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.

For all supported x64-based versions of Windows Server 2008 R2

File name

File version

File size

Date

Time

Platform

Kdcsvc.dll

6.1.7600.20597

429,568

16-Dec-2009

16:18

x64

Kdcsvc.mof

Not applicable

5,300

10-Jun-2009

21:01

Not applicable

Workaround

To work around this issue, reset the password of the problematic user account on the domain controller that is running Windows Server 2008 R2.

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the «Applies to» section.

More Information

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates

Additional file information

Additional file information for Windows Server 2008 R2

Additional files for all supported x64-based versions of Windows Server 2008 R2

File name

Amd64_ace4830253e8e7b2cdbd3bb4f417cba1_31bf3856ad364e35_6.1.7600.20597_none_ec1bf3810896c5c8.manifest

File version

Not applicable

File size

724

Date (UTC)

17-Dec-2009

Time (UTC)

01:36

Platform

Not applicable

—

File name

Amd64_microsoft-windows-k..distribution-center_31bf3856ad364e35_6.1.7600.20597_none_e82d8950c715d523.manifest

File version

Not applicable

File size

35,825

Date (UTC)

16-Dec-2009

Time (UTC)

16:49

Platform

Not applicable

—

File name

Update.mum

File version

Not applicable

File size

1,700

Date (UTC)

17-Dec-2009

Time (UTC)

01:36

Platform

Not applicable

Need more help?

Источник

Hi,

here are some steps to use kerberos authentification against a active directory with OS Version Windows Server 2008 R2 or later on your linux machine.

The default krb5 configuration implementation of the most linux distributions did not work out of the box. I assume that the REALM in /etc/krb5.conf is already configured.

Typical error messages are:

kinit: KDC has no support for encryption type while getting initial credentials
kinit: KDC reply did not match expectations while getting initial credentials
michael@debdev:~# kinit  michael@subdomain.domain.local
Password for michael@subdomain.domain.local:
kinit: KDC has no support for encryption type while getting initial credentials

To eliminate the “KDC has no support for encryption type while getting initial credentials” issue change the default encryption type in the libdefaults section of the /etc/krb5.conf file.

Add the default_tgs_enctypes and default_tkt_enctypes to your config. 

[libdefaults]
      default_realm = SUBDOMAIN.DOMAIN.LOCAL
      default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
      default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

check again 

michael@debdev:~# kinit  michael@subdomain.domain.local
Password for michael@subdomain.domain.local:
kinit: KDC reply did not match expectations while getting initial credentials

If the “KDC reply did not match expectations while getting initial credentials” error occurs, check your /etc/krb5.conf. Ensure that all Realm names are in upper case letters.

[libdefaults]
      default_realm = SUBDOMAIN.DOMAIN.LOCAL
......
[realms]
        SUBDOMAIN.DOMAIN.LOCAL = {
                kdc = DC.SUBDOMAIN.DOMAIN.LOCAL:88
                admin_server = DC.SUBDOMAIN.DOMAIN.LOCAL
                default_domain = SUBDOMAIN.DOMAIN.LOCAL
        }

kinit also needs the realm respective the domain in upper case.

michael@debdev:~# kinit michael@SUBDOMAIN.DOMAIN.LOCAL
Password for michael@SUBDOMAIN.DOMAIN.LOCAL:
michael@debdev:~#
michael@debdev:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: michael@SUBDOMAIN.DOMAIN.LOCAL

Valid starting       Expires              Service principal
23.01.2014 21:35:39  24.01.2014 11:35:44  krbtgt/SUBDOMAIN.DOMAIN.LOCAL@SUBDOMAIN.DOMAIN.LOCAL
        renew until 24.01.2014 21:35:39

For example I used the ticket to get some information about CIFS of a Windows Box

michael@debdev:~# rpcclient win7.subdomain.domain.local -k
rpcclient $> srvinfo
        WIN7.SUBDOMIN.Wk Sv NT
        platform_id     :       500
        os version      :       6.1
        server type     :       0x1003
rpcclient $> getusername
Account Name: michael, Authority Name: SUBDOMAIN

Michael

Advertisment to support michlstechblog.info

My Knowledgebase for things about Linux, Windows, VMware, Electronic and so on…

This website uses cookies to improve your experience and to serv personalized advertising by google adsense. By using this website, you consent to the use of cookies for personalized content and advertising. For more information about cookies, please see our Privacy Policy, but you can opt-out if you wish. Accept Reject Read More

Источник

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

В этой статье рассматриваются некоторые проблемы, которые могут возникнуть. Некоторые из вопросов, которые мы включаем здесь:

  • Проблемы, возникающие при настройке системы
  • Проблемы, возникающие из-за клиентских утилит и сбоев в использовании или управлении средой Kerberos
  • Проблемы с шифрованием KDC
  • Проблемы с клавиатурой

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

Шаг 1: Убедитесь, что на обеих машинах правильно установлен работающий протокол Kerberos.

Шаг 2: Синхронизируйте время на обеих машинах, чтобы убедиться, что они работают в одинаковых временных рамках. В частности, используйте сетевую синхронизацию времени (NTS), чтобы компьютеры находились в пределах 5 минут друг от друга.

Шаг 3: Проверьте, все ли узлы в сетевой службе домена (DNS) имеют правильные записи. При этом убедитесь, что каждая запись в файле хоста имеет соответствующие IP-адреса, имена хостов и полные доменные имена (FQDN). Хорошая запись должна выглядеть так:

IP_address 
FQDN hostname

Устранение неполадок клиентской утилиты Linux Kerberos

Если вам сложно управлять клиентскими утилитами, вы всегда можете использовать следующие три метода для решения проблем:

Способ 1: использование команды Klist

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

bash-2.05$ klist
Ticket cache: /tmp/krb5cc_1002
Default principal: HTTP/sol8sunone.test.com @TEST.COM
Valid starting                    Expires                    Service principal

Tue Nov 22 16:14:03 2022         Tue Nov 22 22:46:03 2014   krbtgt/ www.MaxDestroyer@ANDREYEX.RU

Способ 2: использование команды Kinit для проверки проблем на клиенте KDC

Вы также можете использовать команду Kinit, чтобы подтвердить, есть ли у вас какие-либо проблемы с вашим хостом KDC и клиентом KDC. Утилита Kinit поможет вам получить и кэшировать билет на выдачу билетов для субъекта-службы и пользователя. Проблемы с клиентской утилитой всегда могут возникать из-за неправильного имени участника или неправильного имени пользователя.

Ниже приведен синтаксис Kinit для принципала пользователя:

kinit username

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

С другой стороны, синтаксис Kinit для субъекта-службы аналогичен деталям на снимке экрана ниже. Обратите внимание, что это может варьироваться от одного хоста к другому:

kinit -k[-t keytab_file] principal_name

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

Способ 3: использование команды kinit для проверки проблем с SMP

Вы также можете запустить приведенную ниже команду независимо от того, сработала ли приведенная выше команда комплекта или нет. Это помогает определить, есть ли какие-либо проблемы с хостом SMP. Примечательно, что это более полезно при тестировании вашего сервера на mail.company.com.

Ваша команда kinit будет иметь следующую структуру:

kbd>kinit -S host/mail.company.com@SERVER01.COMPANY.COM

Способ 4: использование команды ktpass

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

Устранение проблем с поддержкой KDC

Kerberos часто может дать сбой из-за множества проблем. Но иногда проблемы могут быть связаны с поддержкой шифрования KDC. Примечательно, что такая проблема приведет к следующему сообщению:

kinit: KDC has no support for encryption type while getting initial credentials

Если вы получили указанное выше сообщение, выполните следующие действия:

  • Убедитесь, что ваши настройки KDC блокируют или ограничивают какие-либо типы шифрования.
  • Убедитесь, что в вашей учетной записи сервера проверены все типы шифрования.

Устранение неполадок с Keytab

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

Шаг 1: Убедитесь, что расположение и имя файла вкладки ключа для хоста аналогичны данным в файле krb5.conf.

Шаг 2: Убедитесь, что хост и клиентские серверы имеют основные имена.

Шаг 3: Подтвердите тип шифрования перед созданием файла вкладки ключа.

Шаг 4: Проверьте правильность файла вкладки ключа, выполнив приведенную ниже команду kinit:

kinit -t C:LinuxMaxDestroyer.keytab HTTP/MaxDestroyer@ANDREYEX.RU

kinit host/fqdn@ANDREYEX.COM

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

kinit -t C:LinuxMaxDestroyer.keytab HTTP/MaxDestroyer@ANDREYEX.RU

kinit host/fqdn@ANDREYEX.COM

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

From Authentication Tools for Joomla! (JAuthTools)

Jump to: navigation, search

This page documents some solutions for common Kerberos issues. It isn’t comprehensive but should give you a guide what to look for when resolving the issues.

Contents

  • 1 Known Errors and Resolutions
    • 1.1 kinit(v5): KRB5 error code 68 while getting initial credentials
    • 1.2 kinit(v5): Permission denied while getting initial credentials
    • 1.3 Client not found in Kerberos database
    • 1.4 kinit(v5): Preauthentication failed while getting initial credentials
    • 1.5 kinit(v5): Key table entry not found while getting initial credentials
    • 1.6 krb5_get_init_creds_password() failed: Clock skew too great
    • 1.7 failed to verify krb5 credentials: Server not found in Kerberos database
    • 1.8 gss_acquire_cred() failed: Miscellaneous failure (No principal in keytab matches desired name)
    • 1.9 gss_accept_sec_context() failed: A token was invalid (Token header is malformed or corrupt)
    • 1.10 gss_accept_sec_context() failed: Miscellaneous failure (Key version number for principal in key table is incorrect)
    • 1.11 Issues with mapuser
    • 1.12 IE prompts for a password on each access
  • 2 Unknown responses
    • 2.1 krb5_get_init_creds_password() failed: KDC reply did not match expectations
    • 2.2 Specified realm `OTHER.REALM.NAME’ not allowed by configuration
    • 2.3 KDC has no support for encryption type

Known Errors and Resolutions

kinit(v5): KRB5 error code 68 while getting initial credentials

Wrong Kerberos domain, check that the Linux box is configured to use the right domain.

kinit(v5): Permission denied while getting initial credentials

Check the permission on your keytab file to ensure that the process can get access to it appropriately.

Client not found in Kerberos database

  • kinit(v5): Client not found in Kerberos database while getting initial credentials
  • krb5_get_init_creds_password() failed: Client not found in Kerberos database

Make sure that you’re typing in the right name and the server has the right name (double check the account tab of the user, especially the realm)

kinit(v5): Preauthentication failed while getting initial credentials

Wrong password — use the right password. This may also occur with keys and a buggy version of ktpass.exe, some versions of ktpass.exe had issues generating keys (Windows 2003 SP1) so upgrading to the latest release should fix this (see Microsoft KB 919557)

kinit(v5): Key table entry not found while getting initial credentials

Regenerate keytab file and make sure that your file is correct.

krb5_get_init_creds_password() failed: Clock skew too great

  • failed to verify krb5 credentials: Clock skew too great

Time between HTTP server and Kerberos server is too big; alternatively may also indicate a client issue. Check that you have NTP setup properly, using the KDC as the primary NTP server.

failed to verify krb5 credentials: Server not found in Kerberos database

Check the default_realms to ensure there is a proper mapping, also check that the host/FQDN@REALM entry exists.

gss_acquire_cred() failed: Miscellaneous failure (No principal in keytab matches desired name)

Check default_realms to ensure there is a domain mapping. Check the keytab file (klist -k /etc/krb5.keytab or similar) to ensure that the appropriate domain is present. Also ensure that your hostname is the FQDN of the machine.

gss_accept_sec_context() failed: A token was invalid (Token header is malformed or corrupt)

Check that the site is in the local domain for IE’s security settings; likely an NTLM token is being sent, see IE not correctly identifying sites in the intranet to help resolve this issue.

gss_accept_sec_context() failed: Miscellaneous failure (Key version number for principal in key table is incorrect)

Wrong key version is being used. Check the key on the server (kinit -k PRINCIPAL) and also restart any client to clear their local cache or restart the server to clear its cache. kerbtray.exe can also delete old tickets. Also note that some versions of ktpass.exe had issues generating keys (Windows 2003 SP1) so upgrading to the latest release should fix this (see http://support.microsoft.com/kb/919557 Microsoft KB 919557])

Issues with mapuser

AD may or may not have had time to properly replicate the user to all DC’s. Ensure that the DC you’re querying is the same as the one you created the user to avoid this as much as possible.

IE prompts for a password on each access

From Windows Authentication and ASP.Net:
Internet Explorer security settings must be configured to enable Integrated Windows authentication. By default, Integrated Windows authentication is not enabled in Internet Explorer 6. To enable the browser to respond to a negotiate challenge and perform Kerberos authentication, select the Enable Integrated Windows Authentication check box in the Security section of the Advanced tab of the Internet Options menu, and then restart the browser.’

Alternatively this may be an issue with the site not being in the intranet zone. IE won’t send authentication details automatically to sites that aren’t located within the intranet zone. See IE not correctly identifying sites in the intranet for more information.

Unknown responses

krb5_get_init_creds_password() failed: KDC reply did not match expectations

See http://mailman.mit.edu/pipermail/kerberos/2007-November/012585.html

Specified realm `OTHER.REALM.NAME’ not allowed by configuration

Another realm is trying to authenticate against the server than is permissable by the servers configuration. This could point to a mismatch between the servers configured realm and the actual realm of the user or the fact that there are multiple realms available and only one configured.

KDC has no support for encryption type

Would indicate that the KDC doesn’t like the encryption protocols being used. If you’re not using the MIT implementation (e.g. Hiemdal) see if switching to MIT works.

Источник

Понравилась статья? Поделить с друзьями:
  • Kerio control initialization error
  • Kdbsync exe не работает что это как исправить
  • Kerio control error 1920
  • Kerberos target resolution error windows server 2019
  • Kerberos security error server manager