Kinit failed to store credentials internal credentials cache error

Параллельные вызовы kinit приводят к повреждению кеша Kerberos Если я пытаюсь выполнить аутентификацию с помощью ключевого слова Kerberos несколько раз параллельно, я случайно получаю сообщения об ошибках, в которых указано, что кеш учетных данных поврежден. Я мог бы воспроизвести эту проблему со следующим сценарием. Тем не менее, в моем реальном случае использования есть процессы, […]

Содержание

  1. Параллельные вызовы kinit приводят к повреждению кеша Kerberos
  2. Параллельные вызовы kinit приводят к повреждению кеша Kerberos
  3. Support Questions
  4. Support Questions
  5. Параллельные вызовы kinit приводят к повреждению кеша Kerberos

Параллельные вызовы kinit приводят к повреждению кеша Kerberos

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

Я мог бы воспроизвести эту проблему со следующим сценарием. Тем не менее, в моем реальном случае использования есть процессы, вызывающие kinit в одно и то же время, и я не могу их контролировать:

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

Есть ли способ заставить kinit “ждать своей очереди” и не обращаться к кешу, если к нему уже обращается другой процесс?

Если несколько процессов создают билеты независимо друг от друга, у них нет причин использовать один и тот же кеш учетных данных. В худшем случае они даже использовали бы разные принципы, и побочные эффекты были бы… интересными.

Решение: измените среду каждого процесса, чтобы KRB5CCNAME на конкретный файл – и предпочтительно в каталоге приложения. Это предотвратит условия гонки и очистит ваш беспорядок.

Частичное решение: поддерживайте один кеш, но не на основе файла (поскольку Linux не имеет возможности принудительно блокировать файл), например, KEYRING .

В любом случае вы имеете право жаловаться на sh… er, неуклюжий способ разработки этих приложений. Или, может быть, они предназначены для работы в изолированных контейнерах?

Источник

Параллельные вызовы kinit приводят к повреждению кеша Kerberos

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

Я мог воспроизвести эту проблему с помощью следующего сценария. Однако в моем реальном варианте использования одновременно вызываются процессы, kinit и я не могу их контролировать:

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

Есть ли способ заставить kinit «ждать своей очереди» и не обращаться к кешу, если к нему уже обращается другой процесс?

Если несколько процессов создают билеты независимо, у них нет причин использовать один и тот же кеш учетных данных. В худшем случае они даже использовали бы другие принципы, и побочные эффекты были бы . интересными.

Решение: измените среду каждого процесса так, чтобы она KRB5CCNAME указывала на конкретный файл — и желательно в каталог конкретного приложения. Это предотвратит состояние гонки и уберет ваш беспорядок.

Частичное решение: поддерживать единый кеш, но не на основе файла (поскольку в Linux нет возможности принудительно установить монопольную блокировку файла), например KEYRING .

В любом случае вы имеете право жаловаться на то, что эти приложения были разработаны с . эээ . неуклюже. Или, может быть, они были разработаны для работы в изолированных контейнерах?

Источник

Support Questions

  • Subscribe to RSS Feed
  • Mark Question as New
  • Mark Question as Read
  • Float this Question for Current User
  • Bookmark
  • Subscribe
  • Mute
  • Printer Friendly Page

Created on ‎07-22-2018 08:49 PM — edited ‎09-16-2022 06:30 AM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

kerberos ticket renewer is not starting. see the below log file data.

Created ‎07-24-2018 09:42 AM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

The error of interest is in your kt_renwer log:

/bin/kinit -k -t /run/cloudera-scm-agent/process/961-hue-KT_RENEWER/hue.keytab -c /var/run/hue/hue_krb5_ccache hue/npmnru01l.vf-nz.internal.vodafone.com@NASA-UAT-VFNZ.COM

kinit: Failed to store credentials: Internal credentials cache error (filename: /var/run/hue/hue_krb5_ccache) while getting initial credentials

The error tells us there was a problem for kinit storing the credentials in the credentials cache located in /var/run/hue/hue_krb5_ccache

I would check that file and parent directory to make sure your hue process user can create the cache file there.

Try running kinit -c /var/run/hue/hue_krb5_ccache

Источник

Support Questions

  • Subscribe to RSS Feed
  • Mark Question as New
  • Mark Question as Read
  • Float this Question for Current User
  • Bookmark
  • Subscribe
  • Mute
  • Printer Friendly Page

Created on ‎02-24-2014 07:14 AM — edited ‎09-16-2022 01:54 AM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

I am currently in the process of enabling security in our cluster (CDH4.5, CM4.8) according the documentation here => http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM4Ent/4.5.4/Configuring-Hadoop-Secur.

Everything went fine until step 14, starting all the services. The service «Kerberos Ticket Renewer» doesn’t start, the latest log entries are:

The logs of the KDC shows:

Feb 24 15:41:33 hadoop-pg-1 krb5kdc[4475](info): AS_REQ (4 etypes <18 17 16 23>) 10.147.210.1: NEEDED_PREAUTH: hue/hadoop-pg-1.cluster@HADOOP-PG for krbtgt/HADOOP-PG@HADOOP-PG, Additional pre-authentication required
Feb 24 15:41:33 hadoop-pg-1 krb5kdc[4475](info): AS_REQ (4 etypes <18 17 16 23>) 10.147.210.1: ISSUE: authtime 1393252893, etypes , hue/hadoop-pg-1.cluster@HADOOP-PG for krbtgt/HADOOP-PG@HADOOP-PG
Feb 24 15:41:35 hadoop-pg-1 krb5kdc[4475](info): TGS_REQ (4 etypes <18 17 16 23>) 10.147.210.1: TICKET NOT RENEWABLE: authtime 0, hue/hadoop-pg-1.cluster@HADOOP-PG for krbtgt/HADOOP-PG@HADOOP-PG, KDC can’t fulfill requested option
Feb 24 15:41:35 hadoop-pg-1 krb5kdc[4475](info): TGS_REQ (4 etypes <18 17 16 23>) 10.147.210.1: TICKET NOT RENEWABLE: authtime 0, hue/hadoop-pg-1.cluster@HADOOP-PG for krbtgt/HADOOP-PG@HADOOP-PG, KDC can’t fulfill requested option

The KDC config looks like:

[realms]
HADOOP-PG = <
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 1d 0h 0m 0s
max_renewable_life = 90d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth +renewable
>

Additionally I set the following:

kadmin.local: modprinc -maxlife «1 day» -maxrenewlife «90 day» +allow_renewable hue/hadoop-pg-1.cluster@HADOOP-PG

Some hints, where to investigate to resolve this issue?

Created ‎02-24-2014 08:22 AM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

Consider the following examples:

First the /etc/krb5.conf In this example a second domain is configured (Active Directory) for cross realm authentication with AES256 encryption being used by AD. Using AES256 means that one must install the JCE Policy Files For JDK6 or the JCE Policy Files for JDK7 to use stron encryption like AES256. Note the Items in bold that are pointed, out, they should be set in that specific file (krb5.condif)

Consider the following for the /var/kerberose/krb5kdc/kdc.conf, calling out items to set in this file as Bold Text , below.

Created ‎02-24-2014 08:22 AM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

Consider the following examples:

First the /etc/krb5.conf In this example a second domain is configured (Active Directory) for cross realm authentication with AES256 encryption being used by AD. Using AES256 means that one must install the JCE Policy Files For JDK6 or the JCE Policy Files for JDK7 to use stron encryption like AES256. Note the Items in bold that are pointed, out, they should be set in that specific file (krb5.condif)

Consider the following for the /var/kerberose/krb5kdc/kdc.conf, calling out items to set in this file as Bold Text , below.

Created ‎02-25-2014 12:26 AM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

thanks for your answer. Seems like adding the lifetime parameters solved the problem. After inserting them, reducing the original renew-lifetime to 7d and restarting all the services it looks good and I can proceed with the doc mentioned in the initial post.

Created on ‎08-18-2014 09:58 AM — edited ‎08-18-2014 10:43 AM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

Im using only kerberos not AD

I get an error please let me know why?

Im trying to run job from sqoop sql to hdfs

Error: org.apache.hadoop.security.AccessControlException: SIMPLE authentication is not enabled. Available:[TOKEN, KERBEROS]

[root@xeon narayana]# vim /var/kerberos/krb5kdc/kdc.conf
——————————

[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88

Источник

Параллельные вызовы kinit приводят к повреждению кеша Kerberos

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

Я мог воспроизвести эту проблему с помощью следующего сценария. Однако в моем реальном варианте использования есть процессы, вызывающие kinit одновременно, и я не могу их контролировать:

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

Есть ли способ заставить kinit «ждать своей очереди» и не обращаться к кешу, если к нему уже обращается другой процесс?

В этом скрипте между каждой строкой помещается инструкция «сна», заставляющая ждать 1–3 секунды между каждым вызовом kinit.

Сценарий нужен только для воспроизведения ошибки. Но в моем реальном варианте использования есть процессы, вызывающие kinit одновременно, и я не могу их контролировать.

Я вижу, что вы используете Unix или Linux. Вы используете версию kinit для ОС или kinit для Java? Если Java, то какая версия JRE / JDK?

Если несколько процессов создают билеты независимо, у них нет причин использовать кеш учетных данных одно и тоже. В худшем случае они даже использовали бы другие принципы, и побочные эффекты были бы . интересными.

Решение: измените среду каждого процесса так, чтобы KRB5CCNAME указывал на определенный файл — и желательно в каталог для конкретного приложения. Это предотвратит состояние гонки и уберет ваш беспорядок.

Частичное решение: поддерживать единый кеш, но не на основе файла (поскольку в Linux нет возможности принудительно установить монопольную блокировку файла), например. KEYRING .

В любом случае вы имеете право жаловаться на то, что эти приложения были разработаны с . эээ . неуклюже. Или, может быть, они были разработаны для работы в изолированных контейнерах?

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

Источник

Источник

Вопрос:

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

Я мог бы воспроизвести эту проблему со следующим сценарием. Тем не менее, в моем реальном случае использования есть процессы, вызывающие kinit в одно и то же время, и я не могу их контролировать:

kdestroy
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK"

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

kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_1645005342) while getting initial credentials
kinit: Failed to store credentials: No credentials cache found (filename: /tmp/krb5cc_1645005342) while getting initial credentials
kinit: Failed to store credentials: Bad format in credentials cache (filename: /tmp/krb5cc_1645005342) while getting initial credentials
OK
OK

Есть ли способ заставить kinit “ждать своей очереди” и не обращаться к кешу, если к нему уже обращается другой процесс?

Лучший ответ:

Если несколько процессов создают билеты независимо друг от друга, у них нет причин использовать один и тот же кеш учетных данных. В худшем случае они даже использовали бы разные принципы, и побочные эффекты были бы… интересными.

Решение: измените среду каждого процесса, чтобы KRB5CCNAME на конкретный файл – и предпочтительно в каталоге приложения. Это предотвратит условия гонки и очистит ваш беспорядок.

Частичное решение: поддерживайте один кеш, но не на основе файла (поскольку Linux не имеет возможности принудительно блокировать файл), например, KEYRING.

В любом случае вы имеете право жаловаться на sh… er, неуклюжий способ разработки этих приложений. Или, может быть, они предназначены для работы в изолированных контейнерах?

Источник

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

Я мог воспроизвести эту проблему с помощью следующего сценария. Однако в моем реальном варианте использования есть процессы, вызывающие kinit одновременно, и я не могу их контролировать:

kdestroy
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK"

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

kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_1645005342) while getting initial credentials
kinit: Failed to store credentials: No credentials cache found (filename: /tmp/krb5cc_1645005342) while getting initial credentials
kinit: Failed to store credentials: Bad format in credentials cache (filename: /tmp/krb5cc_1645005342) while getting initial credentials
OK
OK

Есть ли способ заставить kinit «ждать своей очереди» и не обращаться к кешу, если к нему уже обращается другой процесс?

2 ответа

Лучший ответ

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

Решение: измените среду каждого процесса так, чтобы KRB5CCNAME указывал на определенный файл — и желательно в каталог конкретного приложения. Это предотвратит состояние гонки и уберет ваш беспорядок.

Частичное решение: поддерживать единый кеш, но не на основе файла (поскольку в Linux нет возможности принудительно установить монопольную блокировку файла) , например KEYRING.

В любом случае вы имеете право жаловаться на то, что эти приложения были разработаны с … эээ … неуклюже. Или, может быть, они были разработаны для работы в изолированных контейнерах?


6

Samson Scharfrichter
6 Июл 2018 в 23:49

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

Begin
…

#Assign unused file descriptor e.g. 99 to a file called “kinit_lock.dat”
exec 99 >”kinit_lock.dat”

#try to acquire exclusive lock for “kinit_lock.dat” with timeout of 5 secs.
flock -x -w 5 99

#Invoke kinit
kinit <parameters>

#unlock the kinit lock file
flock -u 99

…
Job script
…

End


0

Leny Thangiah
10 Сен 2020 в 06:29

Источник

Понравилась статья? Поделить с друзьями:
  • Kingston ssd raw read error rate
  • Kings bounty application load error 5 0000065434
  • Kingroot ошибка сети не удалось получить root стратегии под облако
  • Kingroot ошибка сети на андроид
  • Kingroot network error