Received error from kdc 1765328360 preauthentication failed

Failure in kerberos_kinit_password: Client not found in Kerberos database

03/26/2020 21 People found this article helpful 193,804 Views

Description

AD users are able to authenticate and connect to the appliance, but when we check the logs we see the below error message every time a user authenticates

Failure in kerberos_kinit_password: Client not found in Kerberos database

Resolution

Step 1:-1765328360 Preauthentication failed
The appliance does support preauthentication, but this error will occur if there are other issues that cause a preauthentication failure. You should disable preauthentication for the user in Active Directory .

Step 2:- 1765328353 Decrypt integrity check failed
This means that the encryption key stored in the keytab doesn’t match the key stored in the KDC for the principal. You should first reset the GSAs account password in Active Directory and then run ktpass again and verify that the password is entered correctly. We have also found that deleting and recreating the GSA user in Active Directory and following the entire user setup and ktpass registeration commands solves this problem.

Step 3:-1765328378 Client not found in Kerberos database
This means that the principal specified in the keytab was either not found in Active Directory or it was found multiple times. The principal name used in the keytab must match the userPrincipalName entry in ActiveDirectory for only the user account. You can verify the principal name in the keytab by running the klist command: klist -k

Additional Information:

• Verify your content server supports Kerberos

Please verify your content server is using Kerberos (and not just NTLM). To verify Kerberos is used, go directly to the URL of a secure page on the content server using one of the header capturing browser extensions. The HTTP server should return the WWW-Authenticate: Negotiate HTTP header. If the HTTP server does not return the header, then it likely does not support Kerberos.

• Verify your browser supports Kerberos

Your browser also must respond back to the content servers «Negotiate» challenge with a kerberos token embedded in the response (the response should be in the form «Authorization: Negotiate YIIFRwYG. » and not «Authorization: Negotiate TRIM. «). You can also use the MIT Kerberos client to verify kerberos.

How to Test:
Enable require Kerberos preauthentication on AD
Login to portal using Domain Credentials

Troubleshooting:

1. Log in to Active Directory with Admin privilege

2.Select the user right click

3. Now click on Properties > Account tab

4. Under account options make sure «Do not require kerberos preauthentication» is enabled so that you no longer get the kerberos log messages on the SRA appliance.

Источник

Kerberos — AES-256 Keytab не работает

Наша команда AD собирается отключить RC4-HMAC, поэтому я должен изменить наши JBoss-приложения на AES. Я добавил типы aes в krb5.conf и создал новые keytabs, но это, похоже, не работает. Тесты помимо приложения с kinit показывают такие же результаты.

Был аналогичная проблема, но его решение для нас уже было включено. Есть еще один парень (Рик Мориц), у которого моя проблема без ответа.

AD: Windows Server 2016.

krb5.conf

Keytabs

keytab старый RC4:

keytab новый AES256:

kinit тесты (krb5 Version 1.12.5)

аутентификация с паролем (успешная):

аутентификация со старым keytab RC4 (успешная):

аутентификация с новой клавиатурой AES256 (сбой):

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

Старая и новая вкладки были созданы с помощью следующей команды ktpass:

Я уже пробовал с правильным kvno вместо 0 с тем же результатом.

Спасибо за помощь или идеи.

P.S. анонимные MY.DOMAIN и myapp

Тест со свежескомпилированным krb5 1.16

Я объединил советы Самсона Шарфрихтера и Т. Херона, и теперь я вижу разницу между SALT, который я получаю от ktpass при создании keytab, и от трассировки вывода kinit. Но я не знаю, откуда это и как это изменить. В этом случае соль состоит из одного из SPN.

ktpass

кинит след

В Java есть флаги трассировки для отладки Kerberos — нелегко понять, но, по крайней мере, вы можете сравнить сценарии OK / KO и увидеть, где эта чертова штука не работает >> -Djava.security.debug=gssloginconfig,configfile,configparser‌​,logincontext и -Dsun.security.krb5.debug=true

Например, для кода C kinit . Я не знаком с выводом KRB5_TRACE, но это может помочь. k5wiki.kerberos.org/wiki/Debugging_tips

У вас нет субъекта-службы, определенного в синтаксисе ktpass. Вместо этого вы указали принципала пользователя. См. В моей статье хороший пример синтаксиса ktpass (примерно на полпути вниз): social.technet.microsoft.com/wiki/contents/articles/…

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

@Samson Scharfrichter Я добавил параметры, но он не дает больше, чем мой вывод отладки по умолчанию. Я добавляю части логов к своему основному вопросу.

@ T.Heron Каким-то образом приложение уже могло использовать этот UPN и его keytab с RC4. У нас тоже есть несколько SPN (http / myapp.my.domain), и с ним мы получаем те же результаты. Я использовал пользователя в примерах здесь, потому что у меня возникла такая же проблема с KINIT. Так что я думаю, проблема не в приложении, а в самой клавише. Кстати, спасибо за статью. Я собираюсь проверить это сейчас

Мои 2 цента: отключить UDP. Я слышал ужасные истории о странных ошибках, которые исчезли после принудительного использования TCP для клиентов Kerberos .

Правда. И если вы используете Active Directory 2008 или более поздней версии, TCP всегда сначала пробуется, потому что для MaxPacketSize по умолчанию установлено значение 0 в этой версии и во всех более новых версиях. За: support.microsoft.com/en-us/help/244474/…

Убедитесь, что вы удалили SPN из учетной записи Active Directory, связанной с keytab, перед созданием новой keytab. Это малоизвестная проблема. В вашем случае я бы выполнил следующий шестиэтапный процесс, и он должен работать:

setspn -D HTTP/myapp.my.domain MyappEU

Затем сгенерируйте keytab:

ktpass -princ HTTP/myapp.my.domain -mapUser MyappEU@MY.DOMAIN -pass xxxxxxxx -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -kvno 0 -out myapp_eu.keytab_AES

Убедитесь, что нужное вам SPN находится в учетной записи Active Directory:

setspn -L MyappEU

1. Убедитесь, что новое имя участника-службы отражено в поле «Имя пользователя для входа в систему» ​​на вкладке «Учетная запись» учетной записи Active Directory, и установите флажок «Эта учетная запись поддерживает 256-битное шифрование Kerberos AES» ниже:

Источник

Understand Identity Service Engine (ISE) and Active Directory (AD)

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes how Identitity Service Engine (ISE) and Active Directory (AD) communicate, protocols that are used, AD filters, and flows.

Prerequisites

Requirements

Cisco reccomends a basic knowledge of :

• ISE 2.x and Active Directory integration .
• External identity authentication on ISE.

Components Used

• ISE 2.x .
• Windows Server (Active Directory) .

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

AD Protocols

Kerberos Protocol

The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user, and the server to access.

The KDC is installed as part of the Domain Controller (DC) and performs two service functions: The Authentication Service (AS) and the Ticket-Granting Service (TGS).

Three exchanges are involved when the client initially accesses a server resource:

1. AS Exchange.
2. TGS Exchange.
3. Client/Server (CS) Exchange.

• Domain Controller = KDC (AS + TGS).
• Authenticate to AS (the SSO portal) with your password.
• Get a Ticket Granting Ticket (TGT) (a session cookie).
• Request log in to a service (SRV01).
• SRV01 redirects you to KDC.
• Show TGT to KDC – (I am already authenticated)
• KDC gives you TGS for SRV01.
• Redirect to SRV01.
• Show service ticket to SRV01.
• SRV01 verifies/trusts service ticket.
• Service ticket has all my information.
• SRV01 logs me in.

When initially logged on to a network, users must negotiate access and provide a log-in name and password in order to be verified by the AS portion of a KDC within their domain.

The KDC has access to Active Directory user account information. Once authenticated, the user is granted a Ticket Granting Ticket (TGT) that is valid for the local domain.

The TGT has a default lifetime of 10 hours and is renewed throughout the user log-on session without the requirement of the user to re-enter his password.

The TGT is cached on the local machine in volatile memory space and is used to request sessions with services throughout the network.

The user presents the TGT to the TGS portion of the KDC when access to a server service is needed.

The TGS on the KDC authenticates the user TGT and creates a ticket and session key for both the client and the remote server. This information (the service ticket) is then cached locally on the client machine.

The TGS receives the client TGT and reads it with its own key. If the TGS approves of the client request, a service ticket is generated for both the client and the target server.

The client reads its portion with the TGS session key retrieved earlier from the AS reply.

The client presents the server portion of the TGS reply to the target server in the next client/server exchange.

Packet captures from ISE for an authenticated user:

The AS-REQ contains the username. If the password is correct, the AS service provides a TGT encrypted with the user password. The TGT is then provided to the TGT service to get a session ticket.

Authentication is successful when a session ticket is received..

This is an example where the password given by client is wrong:

If the password is wrong the AS request fails and a TGT is not received:

Logs on the ad_agent.log file when password is wrong:

2020-01-14 13:36:05,442 DEBUG ,140574072981248,krb5: Sent request (276 bytes) to RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Received error from KDC: -1765328360/Preauthentication failed,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Preauth tryagain input types: 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 WARNING,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] KRB5 Error code: -1765328360 (Message: Preauthentication failed),LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892

2020-01-14 13:36:05,444 DEBUG ,140574072981248,[LwKrb5InitializeUserLoginCredentials()] Error code: 40022 (symbol: LW_ERROR_PASSWORD_MISMATCH),LwKrb5InitializeUserLoginCredentials(),lwadvapi/threaded/lwkrb5.c:1453

MS-RPC Protocol

ISE uses MS-RPC over SMB, SMB provides the authentication and does not require a separate session to find where a given RPC service is located. It uses a mechanism called “named pipe” to communicate between the client and server.

• Create an SMB session connection.
• Transport RPC messages over SMB/CIFS.TCP port 445 as a transport
• SMB session identifies which port a particular RPC service runs and handles user authentication.
• Connect to hidden share IPC$ for inter-process communication.
• Open an appropriate named pipe for the desired RPC resource/function.

Transact the RPC exchange over SMB.

The negotiate protocol request/response line negotiates the dialect of SMB. The session setup request/response performs the authentication.

Tree Connect Request and Response connect to the requested resource. You are connected to a special share IPC$.

This inter-process communication share provides the means of communication between hosts and also as a transport for MSRPC functions.

At packet 77 is Create Request File and the file name is the name of the connected service (the netlogon service in this example).

At packets 83 and 86, the NetrlogonSamLogonEX request is where you send the username for the client authentication on ISE to the AD at the field Network_INFO.

The NetrlogonSamLogonEX response packet replies with the results.

Some flags values for the NetrlogonSamLogonEX response:
0xc000006a is STATUS_WRONG_PASSWORD
0x00000000 is STATUS_SUCCESS
0x00000103 is STATUS_PENDING

ISE integration with Active Directory(AD)

ISE uses LDAP, KRB, and MSRBC to communicate with AD during the join/leave and authentication process.

The next sections provide the protocols, search format, and mechanisms used to connect to a specific DC on AD and user authentication against that DC.

In the event that the DC becomes offline for any reason, ISE fails over to the next available DC and the authentication process is not affected.

A Global Catalog server (GC) is a domain controller that stores copies of all Active Directory objects in the forest.

It stores a complete copy of all objects in the directory of your domain and a partial copy of all objects of all other forest domains.

Thus, the Global Catalog allows users and applications to find objects in any domain of the current forest with a search for attributes included to GC.

The Global Catalog contains a basic (but incomplete) set of attributes for each forest object in each domain (Partial Attribute Set, PAT).

The GC receives data from all the domain directory partitions in the forest. They are copied with the standard AD replication service.

Join ISE to AD

Prerequisites for Active Directory and ISE integration

1. Verify that you have the privileges of a Super Admin or System Admin in ISE.
2. Use the Network Time Protocol (NTP) server settings to synchronize the time between the Cisco server and Active Directory. The maximum allowed time difference between ISE and AD is 5 minutes
3. The configured DNS on ISE must be able to answer SRV queries for DCs, GCs, and KDCs with or without additional Site information.
4. Ensure that all the DNS servers can answer forward and reverse DNS queries for any possible Active Directory DNS domain.
5. AD must have at least one global catalog server operational and accessible by Cisco, in the domain to which you join Cisco.

Join AD domain

ISE applies Domain Discovery to get information about the join domain in three phases:

1. Queries joined domains—Discovers domains from its forest and domains externally trusted to the joined domain.
2. Queries root domains in its forest—Establishes trust with the forest.
3. Queries root domains in trusted forests—Discovers domains from the trusted forests.

Additionally, Cisco ISE discovers DNS domain names (UPN suffixes), alternative UPN suffixes and NTLM domain names.

ISE applies a DC discovery to get all information about the available DCs and GCs.

1. The join process starts with the input credentials of super admin on AD that exist in the domain itself. If it exists in a different domain or subdomain, the username must be noted in a UPN notation (username@domain).
2. ISE sends a DNS query for all DCs, GCs, and KDCs records. If the DNS reply did not have one of them in its answer then the integration fails with DNS related error.
3. ISE uses the CLDAP ping to discover all DCs and GCs through sent CLDAP requests to the DCs which correspond to their priorities in the SRV record. Tthe first DC response is used and ISE is then connected to that DC.

One factor that is used to calculate the DC priority is the time taken by the DC to response to CLDAP pings; a faster response receives a higher priority.

Note: CLDAP is the mechanism that ISE uses to establish and maintain connectivity with the DCs. It measures the response time until the first DC answer. It fails if you see no answer from DC. Warn if response time is bigger than 2.5 seconds. CLDAP ping all DCs in site (If no site then all DCs in domain). The CLDAP response contains DC site and Client site (the site to which ISE machine is assigned).

1. ISE then receives TGT with ‘join user’ credentials.
2. Generate ISE machine account name with the MSRPC. (SAM and SPN)
3. Search AD by SPN if ISE machine account already exists. If ISE machine does not exist, ISE creates a new one.
4. Open Machine account, set ISE machine account password, and verify ISE machine account is accessible.
5. Set ISE machine account attributes (SPN, dnsHostname, and the like).
6. Get TGT with ISE machine credentials with KRB5 and discover all trusted domains.
7. When the join is complete, ISE node updates its AD groups and associated SIDS and automatically starts the SID update process. Verify that this process can complete on the AD side.

Leave AD domain

When ISE leaves, the AD must consider:

1. Use a full AD admin user to perform the leave processes. This verifies that the ISE machine account is removed from the Active Directory database.
2. If the AD was left without credentials, then the ISE account is not removed from the AD and it must be deleted manually.
3. When you reset ISE configuration from the CLI or restore configuration after a backup or upgrade, it performs a leave operation and disconnects the ISE node from the Active Directory domain. (if joined). However, the ISE node account is not removed from the Active Directory domain.
4. It is recommended to perform a leave operation from the Admin portal with the Active Directory credentials because it also removes the node account from the Active Directory domain. This is also recommended when you change the ISE hostname.

DC failover

When the DC connected to ISE become offline or unreachable for any reason, DC failover is triggered automatically on ISE. DC failover can be triggered by the these conditions:

1. AD connector detects that the currently selected DC became unavailable during some CLDAP, LDAP, RPC or Kerberos communication attempt. In such cases, the AD connector initiates DC selection and fails over to the newly selected DC.
2. DC is up and responds to CLDAP ping, but AD Connector cannot communicate with it for some reason (examples: RPC port is blocked, DC is in ‘broken replication’ state, DC has not been properly decommissioned).

In such cases, the AD connector initiates DC selection with a blocked list (“bad” DC is placed in the blocked list) and tries to communicate with the selected DC. The DC selected in the blocked list is not cached.

AD connector must complete failover within reasonable time (or fail if it is not possible). For this reason, AD connector tries limited number of DCs during failover.

ISE blocks AD Domain Controllers if there is an unrecoverable network or server error to prevent ISE from the use of a bad DC. DC is not added to blocked list if it does not respond to CLDAP pings. ISE only lowers the priority of the DC which does not respond.

ISE-AD communication through LDAP

ISE searches for machine or user in AD with one of the these search formats. If the search was for a machine, then ISE adds “$” at the end of the machine name. This is a list of Identity types which is used to identfy a user in AD:

• SAM name: username or machine name without any domain markup, this is the User Logon Name in AD. Example: sajeda or sajeda$

• CN: is the user display name on AD, it must not be same as the SAM. Example: sajeda Ahmed.

• User Principal Name (UPN): is a combination of the SAM name and the domain name (SAM_NAME@domian). Example: sajeda@cisco.com or sajeda$@cisco.com

• Alternative UPN: is an additional / alternative UPN suffixes that configured in the AD other than domain name. This configuration is added globally in the AD (not configured per user) and it is not necessary to be a real domain name suffix.

Each AD can have multiple UPN suffix(@alt1.com,@alt2.com,…, etc). Example: main UPN (sajeda@cisco.com ), alternative UPN :sajeda@domain1 , sajeda@domain2

• NetBIOS prefixed name: is the domain nameusername of machine name. Example: CISCOsajeda or CISCOmachine$

• Host/prefix with unqualified machine: this is used for machine authentication when the machine name only is used, it is host/machine name only. Example: host/machine

• Host/ prefix with fully qualified machine: this is used for machine authentication when the Machine FQDN is used, usually in case of certificate authentication, it is host/FQDN of the machine. Example: host/machine.cisco.com

• SPN name: The name by which a client uniquely identifies an instance of a service, (examples: HTTP, LDAP, SSH) used for Machine only.

User authentication against AD flow:

1. Resolve Identity and determine identity type — SAM, UPN, SPN. If ISE receive the identity as a username only, then it searches for an associated SAM account in the AD. If ISE receives the identity as a username@domain, then it searches for a matched a UPN or mail in the AD. in both scenarios ISE uses additional filters for machine or username.
2. Search domain or forest (depends on identity type)
3. Keep information about all associated accounts (JP, DN, UPN, Domain)
4. If no associated account is found, then AD replies with user is unknown.
5. Perform MS-RPC (or Kerberos) authentication for each associated account
6. If only a single account matches to input identity and password, then authentication is successful
7. If multiple accounts match the incoming identity, then ISE uses the password to solve the ambiguity so that the account with an associated password is authenticated and the other accounts increase the incorrect password counter by 1.
8. If no account matches the incoming identity and password, then AD replies with wrong password.

ISE Search Filters

Filters are used to identify an entity that want to communicate with AD. ISE always searches for that entity in the users and machines groups.

Examples of search Filters:

1. SAM search: If ISE receives an identity as a username only without any domain markup, then ISE treats this username as a SAM and searches in AD for all machine users or machines that have that identity as a SAM name.

If the SAM name is not unique, ISE uses the password to differentiate between users and ISE is configured to use a passwordless protocol such as EAP-TLS.

There are no other criteria to locate the right user, so ISE fails the authentication with an “Ambiguous Identity” error.

However, if the user certificate is present in Active Directory, Cisco ISE uses binary comparison to resolve the identity.

1. UPN or MAIL search: If ISE receives an identity as a username@domain, ISE searches each forest global catalogs for a match to that UPN identity or Mail identity “identity=matched UPN or email”.

If there is a unique match, Cisco ISE proceeds with the AAA flow.

If there are multiple join points with the same UPN and a password or the same UPN and Mail, Cisco ISE fails the authentication with an “Ambiguous Identity” error.

1. NetBIOS search: If ISE receives an identity with a NetBIOS domain prefix (ex:CISCOsajedah), then ISE searches in the forests for the NetBIOS domain. Once found, it then looks for the supplied SAM name (sajeda in our example)

1. Machine base search: If ISE receives a machine authentication, with a host/prefix identity, then ISE searches the forest for a matched servicePrincipalName attribute.

If a fully-qualified domain suffix was specified in the identity, for example host/machine.domain.com, Cisco ISE searches the forest where that domain exists.

If the identity is in the form of host/machine, Cisco ISE searches all forests for the service principal name.

If there is more than one match, Cisco ISE fails the authentication with an “Ambiguous Identity” error.

Note: Same filters are seen in ISE ad-agent.log files

Note: ISE 2.2 patch 4 and prior and 2.3 patch 1 and prior identified users with the attributes SAM, CN, or both. Cisco ISE, release 2.2 Patch 5 and above, and 2.3 Patch 2 and higher, use only sAMAccountName attribute as the default attribute.

Источник

We’re running a Web Agent and when it processes kerberos

authentication scheme, the Web Agent reports error and it can’t handle

the request :

  [08/05/2019][05:10:22][2484][5060][SmKCC.cpp:111][SmKcc::getCredentials][0000000000000000000000008b260b0a-09b4-5d481cae-4578-020c28a0][*10.0.0.2][][MyWebAgent][/myfederation/mykerberos.asp][][Kerberos Credential Cache login failed with service principal HTTP/[email protected]

  [6316] 1565004402.706001: Getting initial credentials for HTTP/[email protected]

  [6316] 1565004402.706002: Setting initial creds service to krbtgt/[email protected]

  [6316] 1565004402.706003: Looked up etypes in keytab: rc4-hmac

  [6316] 1565004402.706004: Sending request (196 bytes) to MYSERVER.MYDOMAIN.COM

  [6316] 1565004402.706005: Resolving hostname 10.0.0.1

  [6316] 1565004402.706006: Sending initial UDP request to dgram 10.0.0.1:88

  [6316] 1565004402.706007: Received answer from dgram 10.0.0.1:88

  [6316] 1565004402.753000: Response was not from master KDC

  [6316] 1565004402.753001: Received error from KDC: -1765328359/Additional pre-authentication required

  [6316] 1565004402.753003: Processing preauth types: 16, 15, 11, 19, 2

  [6316] 1565004402.753004: Selected etype info: etype rc4-hmac, salt «», params «»

  [6316] 1565004402.753005: Retrieving HTTP/[email protected] from FILE:C:WINDOWSmykeytab.keytab (vno 0, enctype rc4-hmac) with result: 0/Success

  [6316] 1565004402.753006: AS key obtained for encrypted timestamp: rc4-hmac/508C

  [6316] 1565004402.753008: Encrypted timestamp (for 1565004402.215195): plain 301AA011180F32303139303830353131323634325AA105020303489B, encrypted 88975090487894B65A9440FD84E315FE969A5CE6D2CA51B4535DBCBEC64ECF947619425AD48EC1B5B97AB254417AAD9F64FC0EA0

  [6316] 1565004402.753009: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success

  [6316] 1565004402.753010: Produced preauth for next request: 2

  [6316] 1565004402.753011: Sending request (272 bytes) to MYSERVER.MYDOMAIN.COM

  [6316] 1565004402.753012: Resolving hostname 10.0.0.1

  [6316] 1565004402.753013: Sending initial UDP request to dgram 10.0.0.1:88

  [6316] 1565004402.815000: Received answer from dgram 10.0.0.1:88

  [6316] 1565004402.831000: Response was not from master KDC

  [6316] 1565004402.831001: Received error from KDC: -1765328360/Preauthentication failed

How can we fix this ?

0

1

root@servfripa:~# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  addent -password -p admin@MY.DOM -k 1 -e aes256-cts

root@servfripa:~# ktutil 
ktutil:  rkt /etc/krb5.keytab 
ktutil:  l 
slot KVNO Principal 
---- ---- --------------------------------------------------------------------- 
  1    2             host/servfripa.my.dom@MY.DOM 
  2    1                             admin@MY.DOM

ktutil:  rkt /etc/krb5.keytab  
ktutil:  l -e 
slot KVNO Principal 
---- ---- --------------------------------------------------------------------- 
  1    2             host/servfripa.my.dom@MY.DOM (aes256-cts-hmac-sha1-96)  
  2    1                             admin@MY.DOM (aes256-cts-hmac-sha1-96)  
ktutil:

root@servfripa:~# KRB5_TRACE="/dev/stdout" kinit -f admin@MY.DOM -k 
[2350] 1626851868.893962: Getting initial credentials for admin@MY.DOM 
[2350] 1626851868.903866: Looked up etypes in keytab: aes256-cts 
[2350] 1626851868.904208: Sending request (159 bytes) to MY.DOM 
[2350] 1626851868.904791: Initiating TCP connection to stream 192.168.0.20:88 
[2350] 1626851868.905166: Sending TCP request to stream 192.168.0.20:88 
[2350] 1626851868.911604: Received answer (284 bytes) from stream 192.168.0.20:88 
[2350] 1626851868.911656: Terminating TCP connection to stream 192.168.0.20:88 
[2350] 1626851868.911899: Response was from master KDC 
[2350] 1626851868.912014: Received error from KDC: -1765328359/Additional pre-authentication required 
[2350] 1626851868.912099: Processing preauth types: 16, 15, 14, 136, 19, 147, 2, 133 
[2350] 1626851868.912114: Selected etype info: etype aes256-cts, salt "ZuWWT&U'8N#HhF<", params "" 
[2350] 1626851868.912157: Received cookie: MIT 
[2350] 1626851868.912183: PKINIT client has no configured identity; giving up 
[2350] 1626851868.912255: Preauth module pkinit (147) (info) returned: 0/Success 
[2350] 1626851868.912298: PKINIT client has no configured identity; giving up 
[2350] 1626851868.912313: Preauth module pkinit (16) (real) returned: 22/Недопустимый аргумент 
[2350] 1626851868.912326: PKINIT client has no configured identity; giving up 
[2350] 1626851868.912334: Preauth module pkinit (14) (real) returned: 22/Недопустимый аргумент 
[2350] 1626851868.912347: PKINIT client has no configured identity; giving up 
[2350] 1626851868.912356: Preauth module pkinit (14) (real) returned: 22/Недопустимый аргумент 
[2350] 1626851868.912434: Retrieving admin@MY.DOM from FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: 0/Succ
ess 
[2350] 1626851868.912489: AS key obtained for encrypted timestamp: aes256-cts/1735 
[2350] 1626851868.912588: Encrypted timestamp (for 1626851868.911708): plain 301AA011180F32303231303732313037313734385AA1050
2030DE95C, encrypted 61DB80C38CB72434C69FD73CD4CC642F16B20299A928E67E3FBD8DAEEC449304F08FE5CEF9AA5E3129A18E141B678192E341086
C5A722FEC 
[2350] 1626851868.912607: Preauth module encrypted_timestamp (2) (real) returned: 0/Success 
[2350] 1626851868.912614: Produced preauth for next request: 133, 2 
[2350] 1626851868.912632: Sending request (252 bytes) to MY.DOM 
[2350] 1626851868.912736: Initiating TCP connection to stream 192.168.0.20:88 
[2350] 1626851868.912926: Sending TCP request to stream 192.168.0.20:88 
[2350] 1626851868.922303: Received answer (284 bytes) from stream 192.168.0.20:88 
[2350] 1626851868.922353: Terminating TCP connection to stream 192.168.0.20:88 
[2350] 1626851868.922463: Response was from master KDC 
[2350] 1626851868.922635: Received error from KDC: -1765328360/Preauthentication failed 
[2350] 1626851868.922667: Preauth tryagain input types: 16, 14, 14, 136, 19, 147, 2, 133 
kinit: Preauthentication failed while getting initial credentials 
root@servfripa:~#

20 REPLIES 20

I reissued the cert for user2, now it is fine for certutil and p11_child:

[root@redos-client2-s1 ~]# certutil -d /etc/pki/nssdb -L -h all

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Enter Password or Pin for "jacarta":
SUBCA-s1                                                     CT,C,C
ORCA-s1                                                      CT,C,C
user2@pki-test.local                                         u,u,u
[root@redos-client2-s1 ~]# /usr/libexec/sssd/p11_child --pre --nssdb=/etc/pki/nssdb
jacarta
/lib64/libjcPKCS11-2.so
7B34306264303736372D373165302D343161342D393066612D6661346337333862306661637D
- no label found -
MIIE0DCCA7igAwIBAgIUVtFX2+xMgDneBWi8x7b2vLkytpMwDQYJKoZIhvcNAQELBQAwEzERMA8GA1UEAwwIU1VCQ0EtczEwHhcNMjAxMDMwMDgzNzQ0WhcNMjExMDMwMDgzNzQ0WjAdMQswCQYDVQQGEwJSVTEOMAwGA1UEAwwFdXNlcjIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCqwGFDsDrhbjeuChG9A3ZkzuMsA8D/ZicE/UYHdrVbWuMsjKwzbxvEkzOByEHOA1wds5kTxyTuBnh+fe10+gryNQcz8Q4+LUaFZDrJtH7myYU7/6zVHOO0mYJSSLOwKb0uH2TJ4hUI9H+3FvGpqpBU/FnFF9WQBWK3wUQY4garQDF91+Ng27fqQrhSRyWqdQuI2ccOBxKirCgVnIJCm/Nvs8VBMEvycIQoDoBO+jKVpnH3jym+E+TMWaZD7lTbS3mW0Ps5/nzXVhGa+QD90wt9nNogs2YKR6uWeub71+WGv1Kz3BkLvYjV6n53gHyfEAOyHN6vI6qpf5+7MqEZJ4glAgMBAAGjggIQMIICDDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFPMva1ihFSq06/VbLc0GK9UkKOucMGEGCCsGAQUFBwEBBFUwUzBRBggrBgEFBQcwAYZFaHR0cDovL3JlZG9zLXN1YmNhLXMxLnBraS10ZXN0LmxvY2FsOjgwODAvZWpiY2EvcHVibGljd2ViL3N0YXR1cy9vY3NwMDgGA1UdEgQxMC+CHXJlZG9zLXN1YmNhLXMxLnBraS10ZXN0LmxvY2Fsgg5yZWRvcy1zdWJjYS1zMTBFBgNVHREEPjA8gRR1c2VyMkBwa2ktdGVzdC5sb2NhbKAkBgorBgEEAYI3FAIDoBYMFHVzZXIyQHBraS10ZXN0LmxvY2FsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYIKwYBBQUHAwEwgZIGA1UdHwSBijCBhzCBhKBpoGeGZWh0dHA6Ly9yZWRvcy1zdWJjYS1zMS5wa2ktdGVzdC5sb2NhbDo4MDgwL2VqYmNhL3B1YmxpY3dlYi93ZWJkaXN0L2NlcnRkaXN0P2NtZD1jcmwmaXNzdWVyPUNOPVNVQkNBLXMxohekFTATMREwDwYDVQQDDAhTVUJDQS1zMTAdBgNVHQ4EFgQUdxCO623wtRDYJcyT/laswwbHOr0wDgYDVR0PAQH/BAQDAgTwMA0GCSqGSIb3DQEBCwUAA4IBAQAO3i8Mg5QTRr92OiBHmE0GZ4aEHMIYxXa2KGqpIiZ0hThFb/SlQ8588jEI+SmI3B5vPwMXQ/t5GYzh/9OeRJLlH+MOvzYxMUmMkStwixzt9MOW9p8Wi7L0lXmziSXt0fwo5cbIdLMy3RZMoU22ag+G+CjzXa+5Xo3UT+HnDGUo31n4JJ+3fiodR9S3TjiNmtcO7JiXcNu8JNYFz5FCi5/JZQSuwSSYJ60xMJrmkNJHsxbyudOzKHIun+oRFnRbmq4K4G7w+9r6vVHrAcQdGOqIGrtrtmJIjBKn5EcAziLH76geMzog1egQFJ9xps3yG21rdAFHp/5BeN5L8dvqizEO
[root@redos-client2-s1 ~]# /usr/libexec/sssd/p11_child --pre --nssdb=/etc/pki/nssdb | tail -1 | base64 -d > user2.der
[root@redos-client2-s1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: adm1@PKI-TEST.LOCAL

Valid starting       Expires              Service principal
30.10.2020 11:35:02  30.10.2020 21:35:02  krbtgt/PKI-TEST.LOCAL@PKI-TEST.LOCAL
    renew until 06.11.2020 11:35:02
30.10.2020 12:23:33  30.10.2020 21:35:02  ldap/redos-dc-s1.pki-test.local@
    renew until 06.11.2020 11:35:02
30.10.2020 12:23:33  30.10.2020 21:35:02  ldap/redos-dc-s1.pki-test.local@PKI-TEST.LOCAL
    renew until 06.11.2020 11:35:02
[root@redos-client2-s1 ~]# ldapsearch -Y GSSAPI -H ldap://redos-dc-s1.pki-test.local -b 'dc=pki-test,dc=local' samaccountname=user2 dn
SASL/GSSAPI authentication started
SASL username: adm1@PKI-TEST.LOCAL
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=pki-test,dc=local> with scope subtree
# filter: samaccountname=user2
# requesting: dn 
#

# user2, corp, pki-test.local
dn: CN=user2,OU=corp,DC=pki-test,DC=local

# search reference
ref: ldap://pki-test.local/CN=Configuration,DC=pki-test,DC=local

# search reference
ref: ldap://pki-test.local/DC=DomainDnsZones,DC=pki-test,DC=local

# search reference
ref: ldap://pki-test.local/DC=ForestDnsZones,DC=pki-test,DC=local

# search result
search: 4
result: 0 Success

# numResponses: 5
# numEntries: 1
# numReferences: 3

[root@redos-client2-s1 ~]# cat user2.ldif
dn: CN=user2,OU=corp,DC=pki-test,DC=local
changetype: modify
add: userCertificate
userCertificate:< file:user2.der

[root@redos-client2-s1 ~]# ldapmodify -Y GSSAPI -H ldap://redos-dc-s1.pki-test.local -f user2.ldif
SASL/GSSAPI authentication started
SASL username: adm1@PKI-TEST.LOCAL
SASL SSF: 56
SASL data security layer installed.
modifying entry "CN=user2,OU=corp,DC=pki-test,DC=local"

[root@redos-client2-s1 sssd5]# KRB5_TRACE=/dev/stdout kinit -X X509_user_identity='PKCS11:module_name=/lib64/libjcPKCS11-2.so:token=jacarta:certid=7B34306264303736372D373165302D343161342D393066612D6661346337333862306661637D' user2@PKI-TEST.LOCAL
[10847] 1604050473.495999: Getting initial credentials for user2@PKI-TEST.LOCAL
[10847] 1604050473.496001: Sending unauthenticated request
[10847] 1604050473.496002: Sending request (208 bytes) to PKI-TEST.LOCAL
[10847] 1604050473.496003: Sending initial UDP request to dgram 192.168.42.10:88
[10847] 1604050473.496004: Received answer (277 bytes) from dgram 192.168.42.10:88
[10847] 1604050473.496005: Response was from master KDC
[10847] 1604050473.496006: Received error from KDC: -1765328359/Additional pre-authentication required
[10847] 1604050473.496009: Preauthenticating using KDC method data
[10847] 1604050473.496010: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ENC-TIMESTAMP (2), PA-ETYPE-INFO2 (19)
[10847] 1604050473.496011: Selected etype info: etype aes256-cts, salt "PKI-TEST.LOCALuser2", params "x00x00x10x00"
jacarta                          PIN: 
[10847] 1604050482.522299: PKINIT client has no configured identity; giving up
[10847] 1604050482.522300: Preauth module pkinit (16) (real) returned: 22/Недопустимый аргумент
[10847] 1604050482.522301: PKINIT client ignoring draft 9 offer from RFC 4556 KDC
[10847] 1604050482.522302: Preauth module pkinit (15) (real) returned: -1765328360/Preauthentication failed
Password for user2@PKI-TEST.LOCAL: 
^C
[10847] 1604050484.172134: Preauth module encrypted_timestamp (2) (real) returned: -1765328252/Password read interrupted
kinit: Password read interrupted while getting initial credentials

but now I don’t get PIN prompt:

$su user2
su: authentication failure

sssd_pam.log
sssd_pki-test.local.log

Symptoms

First see How to analyze the log files to identify single-sign on (SSO) issues .

Single sign-on fails. In awingu-worker-smc.service.log, a similar error can be seen:

2023-01-26 07:54:34.551110 someawinguhost awingu-worker-smc.service[manage.py:25766]: Using specified cache: /etc/awingu/domains/SOMEAWINGUDOMAIN/9a98da27-9203-4510-b3f1-993997c20c84/kerberos/kerberos_credentials_cache
Using principal: someuser@somedomain.org@SOMEWINDOWSDOMAIN.ORG
PA Option X509_user_identity = FILE:/etc/awingu/domains/SOMEAWINGUDOMAIN/9a98da27-9203-4510-b3f1-993997c20c84/certificate.pem,/etc/awingu/domains/SOMEAWINGUDOMAIN/9a98da27-9203-4510-b3f1-993997c20c84/private_key.pem
[15543] 1674719674.309931: Getting initial credentials for someuser@somedomain.org@SOMEWINDOWSDOMAIN.ORG
[15543] 1674719674.309933: Sending unauthenticated request
[15543] 1674719674.309934: Sending request (219 bytes) to SOMEWINDOWSDOMAIN.ORG
[15543] 1674719674.309935: Resolving hostname SOMEWINDOWSDOMAIN.ORG
[15543] 1674719674.309936: Sending initial UDP request to dgram 10.1.2.3:88
[15543] 1674719674.309937: Received answer (214 bytes) from dgram 10.1.2.3:88
[15543] 1674719674.309938: Sending DNS URI query for _kerberos.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309939: No URI records found
[15543] 1674719674.309940: Sending DNS SRV query for _kerberos-master._udp.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309941: Sending DNS SRV query for _kerberos-master._tcp.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309942: No SRV records found
[15543] 1674719674.309943: Response was not from master KDC
[15543] 1674719674.309944: Received error from KDC: -1765328359/Additional pre-authentication required
[15543] 1674719674.309947: Preauthenticating using KDC method data
[15543] 1674719674.309948: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
[15543] 1674719674.309949: Selected etype info: etype aes256-cts, salt "SOMEWINDOWSDOMAIN.ORGsomeuser", params ""
[15543] 1674719674.309950: PKINIT loading CA certs and CRLs from FILE
[15543] 1674719674.309951: PKINIT client computed kdc-req-body checksum 9/2B2890045D086634ED8C98F640115ED6BCE72DF5
[15543] 1674719674.309953: PKINIT client making DH request
[15543] 1674719674.309954: Preauth module pkinit (16) (real) returned: 0/Success
[15543] 1674719674.309955: Produced preauth for next request: PA-PK-AS-REQ (16)
[15543] 1674719674.309956: Sending request (5959 bytes) to SOMEWINDOWSDOMAIN.ORG
[15543] 1674719674.309957: Resolving hostname SOMEWINDOWSDOMAIN.ORG
[15543] 1674719674.309958: Initiating TCP connection to stream 10.1.2.3:88
[15543] 1674719674.309959: Sending TCP request to stream 10.1.2.3:88
[15543] 1674719674.309960: Received answer (137 bytes) from stream 10.1.2.3:88
[15543] 1674719674.309961: Terminating TCP connection to stream 10.1.2.3:88
[15543] 1674719674.309962: Sending DNS URI query for _kerberos.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309963: No URI records found
[15543] 1674719674.309964: Sending DNS SRV query for _kerberos-master._udp.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309965: Sending DNS SRV query for _kerberos-master._tcp.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309966: No SRV records found
[15543] 1674719674.309967: Response was not from master KDC
[15543] 1674719674.309968: Received error from KDC: -1765328322/Client not trusted
[15543] 1674719674.309970: Recovering from KDC error 62 using preauth mech PA-PK-AS-REQ (16)
[15543] 1674719674.309971: Preauth tryagain input types (16): (empty)
[15543] 1674719674.309972: Preauth module pkinit (16) tryagain returned: -1765328360/Preauthentication failed
[15543] 1674719674.309973: Retrying AS request with master KDC
[15543] 1674719674.309974: Getting initial credentials for someuser@somedomain.org@SOMEWINDOWSDOMAIN.ORG
[15543] 1674719674.309976: Sending unauthenticated request
[15543] 1674719674.309977: Sending request (219 bytes) to SOMEWINDOWSDOMAIN.ORG (master)
[15543] 1674719674.309978: Sending DNS URI query for _kerberos.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309979: No URI records found
[15543] 1674719674.309980: Sending DNS SRV query for _kerberos-master._udp.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309981: Sending DNS SRV query for _kerberos-master._tcp.SOMEWINDOWSDOMAIN.ORG.
[15543] 1674719674.309982: No SRV records found
kinit: Client not trusted while getting initial credentials

Cause

The client is not trusted by the Kerberos Domain Controller(s).

There are a variety of causes for this. Usually, the Windows Event Viewer of the Kerberos Domain Controller has a more specific indication.

Most common reasons:

• The Certification Revocation List (CRL) can not be reached.
• Windows Time Service is incorrect (or does not match time of Awingu appliance).
• Awingu SubCA certificate is not present on all Kerberos Domain Controllers, or it is no longer valid (expired or revoked).
• For this error, there is typically a very decent indication in the Windows Event Viewer of the KDC server. Check event 21: ​Windows Event Viewer — Kerberos events . 

Resolution

Narrowing down the cause

The Windows Event Viewer on the Kerberos Domain Controllers helps to identify the cause. 
After applying a solution, make sure to validate if it worked. If it’s still not working, confirm whether the cause is still the same.

To find out the cause, try running the following PowerShell snippet as an administrator. 
Mind adjusting the host names to match the domain controllers in this Windows environment.

     Get-EventLog -LogName 'System' -Source 'KDC' -After
     (Get-Date).AddDays(-1) -ComputerName dc01, dc02 | fl MachineName,
     EventId, TimeGenerated, Message | Out-File
     '$env:userprofiledesktopkdc_events.txt'

Check the contents of the file.

Alternatively, at the individual Kerberos Domain Controller(s):

1. Open the Windows Event Viewer.
2. Navigate to Custom Views > Administrative Events.
3. Look for log entries with Event ID 21 originating from Kerberos-Key-Distribution-Center («source»).

Mind that Event ID 21 comes with a generic first part of the description: The client certificate for the user SOMEDOMAINsomeuser is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they’re attempting to use for smartcard logon.

However, after that, one of these more specific messages will follow:

The chain status was : A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Most common cause: the time between the Kerberos Domain Controller(s) and the Awingu appliance is not in sync. Try to have all of them in sync with real world time.

See Check the time on an Awingu appliance .

The chain status was : A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.

If still not working:

• Make sure any intermediate certificates and the root CA certificate present in Awingu’s SubCA certification path are also published.

• Make sure they’re also present in the local certificate store of the Kerberos Domain Controllers.

The chain status was : The revocation function was unable to check revocation because the revocation server was offline.

See Microsoft Windows Server: Verify retrieval of Certificate Revocation List (CRL)

The chain status was : A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.

Most common cause: the time between the Kerberos Domain Controller(s) and the Awingu appliance is not in sync. Try to have all of them in sync with real world time.

See Check the time on an Awingu appliance .

Verify whether the Awingu SubCA certificate is properly imported in the NTAuth store
certutil -viewstore -enterprise NTAuth

Verify whether all the other certificates in the certification path of the Awingu SubCA are all trusted by the domain controller(s)

If the above solutions didn’t resolve the issue, please contact the support team.