Kinit no supported encryption types config file error while getting initial credentials

samba + авторизация ad косяк Добрый день, хочу настроить samba в качестве файлового сервера настроил krb Пытаюсь получить тикет пишет Что делаю не так? Очевидно же пишет что не совпадают типы шифрования. Если вы пытаетесь подключиться к домену Windows, то попробуйте такие наборы: Поменял тоже самое. Не чего не поменялось. Здравствуйте, а что за […]

Содержание

  1. samba + авторизация ad косяк
  2. astralinux в домене windows 2003
  3. gotovtsev
  4. gotovtsev
  5. Support Questions
  6. «KDC has no support for encryption type» when setting up cross-realm trust between MIT Kerberos and Active Directory
  7. 2 Answers 2
  8. Related
  9. Hot Network Questions
  10. Subscribe to RSS
  11. Kinit no supported encryption types config file error while getting initial credentials
  12. Answered by:
  13. Question

Добрый день, хочу настроить samba в качестве файлового сервера настроил krb

Пытаюсь получить тикет пишет

Что делаю не так?

Очевидно же пишет что не совпадают типы шифрования. Если вы пытаетесь подключиться к домену Windows, то попробуйте такие наборы:

Поменял тоже самое. Не чего не поменялось.

Здравствуйте, а что за система у Вас стоит на контроллере домена (DC1.PROHORY.LOCAL)?

Чем не устраивают рекомендованные настройки из официальной вики самбы? https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member

Добрый день, Windows server 2003, да на DC1.PROHORY.LOCAL

Ну видать потому что не чего не работает.

Попробуйте вместо приведенных Вами строк добавить следующие:

Не работает, уже не знаю что делать с этим поганим керберосом

Не работает, уже не знаю что делать с этим поганим керберосом

Сравнил со своим файлом — у меня вот эти строки:

закомментированы. Отсутствует вот эти строки:

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

На всякий случай, еще совет из разряда шаманских — поменять пароль на контроллере домена для пользователя mannaz.

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

Источник

astralinux в домене windows 2003

gotovtsev

New member

Хочу попробовать использовать astralinux в качестве файлового сервера в домене windows 2003.
Согласно мануалу ввел астру в домен. Затем пробую настроить samba и всё прочее как описывается в этом мануале.

Проблема возникла с настройкой kerberos. При проверке kinit administrator@REGISTRYOFFICE система выводит
сообщение: kinit: KDC has no support for encryption type while getting initial credentials.

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

Судя по всему загвоздка именно в настройках kerberos. Может кто-то сможет помочь в решении данной проблемы?

Содержимое файла krb5.conf

gotovtsev

New member

Модифицировал файл krb5.conf добавив в него:
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 RC4-HMAC DES-CBC-CRC DES3-CBC-SHA1 DES-CBC-MD5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 RC4-HMAC DES-CBC-CRC DES3-CBC-SHA1 DES-CBC-MD5
preferred_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 RC4-HMAC DES-CBC-CRC DES3-CBC-SHA1 DES-CBC-MD5

#astra-winbind
[libdefaults]
default_realm = REGISTRYOFFICE
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
fcc-mit-ticketflags = true
dns_lookup_realm = false
dns_lookup_kdc = true
v4_instance_resolve = false
v4_name_convert = <
host = <
rcmd = host
ftp = ftp
>
plain = <
something = something-else
>
>

default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 RC4-HMAC DES-CBC-CRC DES3-CBC-SHA1 DES-CBC-MD5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 RC4-HMAC DES-CBC-CRC DES3-CBC-SHA1 DES-CBC-MD5
preferred_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 RC4-HMAC DES-CBC-CRC DES3-CBC-SHA1 DES-CBC-MD5

[realms]
REGISTRYOFFICE = <
kdc = SERVER.REGISTRYOFFICE
admin_server = SERVER.REGISTRYOFFICE
default_domain = REGISTRYOFFICE
>

[domain_realm]
.registryoffice = REGISTRYOFFICE
registryoffice = REGISTRYOFFICE
[login]
krb4_convert = true
krb4_get_tickets = false

Источник

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 ‎07-28-2018 06:43 AM

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

i am getting below error when i tried to enbale kerberos using Cloudera Manager after setting up kdc server and admin principal.

Enable Kerberos for Cluster 1

Created on ‎07-28-2018 06:44 AM — edited ‎07-28-2018 07:29 AM

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

i followed this blog but didint work.

nothing worked for me.

my krb5.conf file

[root@aa1 singhkabir880]# cat /etc/krb5.conf#

Configuration snippets may be placed in this directory as wellincludedir /etc/krb5.conf.d/

Kindly suggest how to move further.

Created ‎01-31-2019 09:55 PM

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

any suggestions on this??

Created on ‎12-17-2020 06:52 PM — edited ‎12-17-2020 06:58 PM

  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content
  • Backup your /etc/krb5.conf on all the hosts
  • Verify the encryption types supported from your Kerberos server (If MIT — Check «supported_enctypes» in /var/kerberos/krb5kdc/)
  • Check the » Kerberos Encryption Types» under CM > Administration > Security > Kerberos Credentials > Configuration. Include the encryption types supported by your KDC.
  • Enable «Manage krb5.conf through Cloudera Manager» from the same configuration page.
  • Select «Deploy Kerberos client configuration» from the drop-down near your cluster.
  • Once deployed, verify if the krb5.conf on the agent nodes have the encryption types included as mentioned in CM.
  • If CM server is running on stale kerberos configuration, copy the krb5.conf from one of the agent nodes to CM server.
  • Regenerate the principals from CM. (If this is success, you should be able to restart CM and CDH services).

Источник

«KDC has no support for encryption type» when setting up cross-realm trust between MIT Kerberos and Active Directory

I am currently setting up an environment where I have a set of Solaris and Linux machines, using a dedicated Krberos 5 realm (MIT, on Solaris 11, krb5-config —version returns: Solaris Kerberos (based on MIT Kerberos 5 release 1.6.3) ). We also have an Active Directory (Windows 2003) server for a separate realm.

My goal is to have all users in the AD server, and the host/nnn, nfs/nnn and cifs/nnn principals in the MIT-based realm. I’m trying to set up cross-domain trust between these two realms.

Assume the following:

  • Unix realm: EXAMPLE.COM
  • AD realm: AD.EXAMPLE.COM

I’ve set up the AD cross-realm trust according to the Microsoft documentation, with two-way trust.

What happens is that cross-realm authentication only works in one direction. From AD to Unix works:

But, the opposite does not, and gives me an error message: KDC has no support for encryption type while getting credentials for adtest@AD.EXAMPLE.COM

Note that I have tried all sorts of different things. Some of those being:

  • Configured the cross-realm keys on the Unix side to use rc4-hmac only, with the effect that the call to kvno won’t even be able to find the KDC on the Microsoft side.
  • Added default_tkt_enctypes and default_tgs_enctypes entries to force the use of rc4-hmac . This was necessary to just get login authentication against AD to work.

What could be the cause of this, and how can I figure out what is actually going on? In particular, it would be very helpful to know exactly what encryption type it’s trying to use which the KDC has no support for. It would also be useful to know which KDC that sent the error.

For completeness, here is the content of the krb5.conf file:

2 Answers 2

I have solved the problem. I’m posting a reply here in case someone else faces the same issue.

The solution was very simple. I needed to make sure that the cross-realm authentication principals were created with a single encoding type, of type rc4-hmac :

As far as I can tell, what happens is that the MIT KDC uses the most secure encoding type when sending the ticket to the AD server. The AD server is unable to handle that encoding and thus replied with the error that the encryption type is not supported. By only having a single encoding type for the principals, the MIT server will use that type when talking to the AD server.

I solved this by checking the error in the journal. The error stated:
— Logs begin at Tue 2018-05-22 13:03:55 UTC, end at Mon 2018-06-18 10:41:01 UTC. —
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Resolving: _ldap._tcp.local.domain
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Performing LDAP DSE lookup on: 10.x.x.1
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Performing LDAP DSE lookup on: 10.x.x.30
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Performing LDAP DSE lookup on: 10.x.x.60
Jun 18 10:40:55 nlxxp1 realmd[1609]: * Successfully discovered: local.domain
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Assuming packages are installed
Jun 18 10:41:00 nlxxp1 realmd[1609]: * LANG=C /usr/sbin/adcli join —verbose —domain local.domain —domain-realm LOCAL.DOMAIN —domain-controller 10.x.x.1 —login-type user —login-user localuser —stdin-password
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Using domain name: local.domain
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Calculated computer account name from fqdn: NLXXP1
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Using domain realm: local.domain
Jun 18 10:41:00 nlxxp1 realmd[1609]: * Sending netlogon pings to domain controller: cldap://10.x.x.1
Jun 18 10:41:01 nlxxp1 realmd[1609]: * Received NetLogon info from: dc.local.domain
Jun 18 10:41:01 nlxxp1 realmd[1609]: * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-QudocS/krb5.d/adcli-krb5-conf-8Gyp0B
Jun 18 10:41:01 nlxxp1 realmd[1609]: ! Couldn’t authenticate as: localuserc@LOCAL.DOMAIN: KDC has no support for encryption type
Jun 18 10:41:01 nlxxp1 realmd[1609]: adcli: couldn’t connect to local.domain domain: Couldn’t authenticate as: localuser@LOCAL.DOMAIN: KDC has no support for encryption type
Jun 18 10:41:01 nlxxp1 realmd[1609]: ! Failed to join the domain

My domain is a mixed domain with a 2003 DC.
After I went into DNS and changed the _ldap._tcp.local.domain record of the 2003 DC (I gave it a heavier weight 400) It picked up a newer (2012R2 DC) which was able to join the server to the domain.

I guess the encryption type used was not supported by the 2003 DC.

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Kinit no supported encryption types config file error while getting initial credentials

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Good Evening,
I have recently stood up a 2008 R2 Domain Controller (and GC). All was running well, but we have found issues with the KDC on this server not issuing tickets for users of a few of our web apps that utilise SSO, namely SAP Portal (J2EE) and Duet (the same).

Both these apps utilise the DES_CBC_MD5 encryption type. The user accounts they run as are configured in AD to «use DES encryption methods». This works absolutely perfectly with our existing 2003 Domain controllers, tickets are issued successfully and users are logged on.

Users who authenticate against the new 2008 server however do NOT get issued a kerberos ticket at all. The server logs an event 16, Kerberos-Key-Distribution-Center error, with the following text:

While processing a TGS request for the target server HTTP/sapserver.domain.tld, the account user@DOMAIN.TLD 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 Service Account will generate a proper key.

The requested etypes are the DES methods, DES-CBC-MD5 and DES-CBC-CRC. I do NOT want to try and reset the service account until I have tried everything possible, especially as it appears to be working at the moment.

Capturing network traffic shows the server returning a ETYPE_NOT_SUPPORTED error.

We do have other web apps using SSO using kerberos tickets that work no problem with the new 2008R2 DC, however these use RC4 encryption methods.

What I have tried:
1. I have enabled these DES methods, under Computer Configuration/Windows Settings/Local Policies/Security Options/Network Security: Configure available encryption types for Kerberos, enabling All but «Future Encryption Types». Rebooted DC, same issue.
2. As per http://support.microsoft.com/default.aspx/kb/961302 I configured the KdcUseRequestedEtypesForTickets key. Restarted server. I was then issued a ticket, but the Ticket Encryption type was RC4, while the key encryption type was DES-CBC-MD5, which meant SSO did not work.
3. Various debugging/extra logging etc, nothing useful beyond the first error.

Does anyone have any ideas or experience with this type of situation. The 2008 DC is currently powered off and holding up our NPS/NAP deployment until I can get this resolved.

Источник

Источник

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

Источник

Troubleshooting Kerberos kinit problems

Error message: kinit: krb5_get_init_creds: Error from KDC: CLIENT EXPIRED

Problem: Your Kerberos account has expired.

Solution: Please see the User Accounts web page for more information on renewing your Kerberos account.

Error message: kinit(v5): Cannot find KDC for requested realm while getting initial credentials

Problem: /etc/krb5.conf file does not contain .FNAL.GOV information.

Solutions:

  1. Replace /etc/krb5.conf with your OS-specific Fermilab-supplied version of krb5.conf.
  2. Modify /etc/krb5.conf adding Fermilab-specific stanzas as instructed in the User Accounts web page.
  3. If you do not have permission to modify /etc/krb5.conf, copy Fermilab-supplied version into your home area, and execute export KRB5_CONFIG=$HOME/krb5.conf to tell all Kerberos commands to use the user’s copy of krb5.conf.

Related problem:

On Macintosh computers, Kerberos is installed on all recent versions. However, there are two locations and names for krb5.conf,

/etc/krb5.conf

and

/Library/Preferences/edu.mit.Kerberos

(Note: the file in /Library is named edu.mit.Kerberos, not krb5.conf.) Either will work, but you should only have one.

Error message: kinit: Unable to acquire credentials for 'user@FNAL.GOV': Cannot contact any KDC for realm 'FNAL.GOV'

Problem: You are behind a firewall or are using an internet connection which has a “NAT” (Network Address Translation), such as on a home wireless router.

Solutions:

Step 1: Check your connectivity, as shown below, to one of the Fermilab Kerberos authentication servers (such as krb-fnal-1.fnal.gov) to make sure you can reach the server at the other end. If successful move to step 2. If fail, send us email at lqcd-admin@fnal.gov.

[@mylaptop ~]$ telnet krb-fnal-1.fnal.gov 88
Trying 131.225.110.105...
Connected to krb-fnal-1.fnal.gov.
Escape character is '^]'.
^]
 
telnet> quit
Connection closed.

OR, in case of some mac OS versions that are missing the telnet utility, use the nc utility as follows:

[@mylaptop ~]$ nc -vz krb-fnal-1.fnal.gov 88
Connection to krb-fnal-1.fnal.gov port 88 [tcp/kerberos] succeeded

Step 2: Request an address-less Kerberos ticket as follows:

kinit -a username@FNAL.GOV

If you do

klist -a

you should see as the last line

Addresses: (none)

Error message: kinit: Preauthentication failed while getting initial credentials

Problem: kinit fails with preauthentication error.

Solutions:

  1. Usually the problem is simply that you have typed in your kerberos password incorrectly. Please try again.
  2. If you have lost your kerberos password, call the Fermilab Service Desk at (630) 840 2345, during business hours to have the password reset.
  3. Occasionally this is not a password problem, but a problem with your system’s clock. Make sure that the date command returns a time correct to within 5 minutes.
Error message: kinit: krb5_get_init_creds: Too large time skew

Problem: kinit fails with time skew message.

Solution:

Your system clock must be within 5 minutes of the correct value.

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

Problem: kinit fails with complaint about encryption type.

Solutions:

This problem appears on recent Ubuntu and related Linux distributions. To fix, edit /etc/krb5.conf file, and in the [libdefaults] section add

allow_weak_crypto = true

Error message: kinit: Client not found in Kerberos database while getting initial credentials

Problem: kinit fails with database complaint.

Solutions:

  1. Your kerberos principal may differ from your username on your local system. Use kinit username@FNAL.GOV where username is your Fermilab kerberos principle. kinit without options will default to using your local username.
  2. Your Fermilab ID or Visitor ID has expired. Please see the User Accounts web page for more information on renewing your Fermilab ID.
Error message: kinit: Client's entry in database has expired

Problem: kinit fails because of an expired password

Solutions:

  1. You must change your kerberos password once a year with the kpasswd command. You can try to change your password, even if it is expired, by using kpasswd on your local machine. More detailed instructions are available here.
  2. You can also call the Fermilab Service Desk at (630) 840 2345, during business hours to have the password reset.
Error message: kinit: Password incorrect

Problem: If you are sure your Kerberos password is correct but you are on a MAC OS 10.10 (Yosemite) kinit will fail because the Kerberos pass phrase is DES encoded, which Yosemite no longer accepts.

Solutions: 

You will need to reset your Kerberos password as follows:

  1. You have access to a non-Yosemite machine with Kerberos client software installed, do kinit to obtain a Kerberos ticket and then SSH to one of our head nodes, for example lq.fnal.gov. Once there do a kpasswd to change your Kerberos password. Alternatively, you may call the Fermilab Service Desk at (630) 840 2345, during business hours and request that they reset your kerberos password. 
  2. Update the krb5.conf file on your Yosemite machine with the latest version from Fermilab-supplied version posted here.
  3. On your Yosemite machine, go ahead and attempt kinit and ssh, which should now work.

Troubleshooting SSH problems

Error message: ssh_dispatch_run_fatal: Connection to 131.225.202.32: unexpected internal error

Problem: You may have just upgraded to the latest Mac OS X version or changed the SSH options on your client.

Solution: Try to “ssh -o GSSAPIKeyExchange=no lq.fnal.gov” to one of our servers. If it works then add “GSSAPIKeyExchange no” to your SSH client config file (e.g. /etc/ssh/ssh_config).

See also: The CMS support group has posted some information specifically addressing the upgrade to Mac OS Big Sur. Visit their troubleshooting page for more information on changes with Big Sur and issues with Anaconda affecting Kerberos authentication.

Error message: permission denied

SSH login failures will be indicated by a permission denied message. If none of the solutions below fixes your problem please email the output of the command “ssh -vvv lq.fnal.gov” to lqcd-admin@fnal.gov for further assistance.

Problem: Kerberos client and SSH using different credential cache file locations.

Solution: We have mostly encountered this on MAC 10.9.x versions where Kerberos clients are installed from two different sources. In such a situation Kerberos client binaries end up in /opt/local/bin and in /usr/bin. Use the Kerberos client kinit installed in /usr/bin to obtain a Kerberos ticket. Also make sure there is a subdirectory .ssh in your home directory. Make sure the subdirectory has a file named config with the following lines:

Host *.fnal.gov
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPITrustDNS yes

Problem: Not having a kerberos ticket granting ticket (TGT), or having an expired TGT.

Solution: Verify with the klist -f command that you have a ticket. If you don’t have a ticket, or have an expired ticket, get a new ticket with kinit as follows:

lqcdp4ee:~$ kinit -fr 7d username@FNAL.GOV
lqcdp4ee:~$ klist -f
Ticket cache: /tmp/krb5cc_1234
Default principal: username@FNAL.GOV
 
Valid starting ·· Expires·········· Service principal
08/17/12 09:31:16 08/18/12 11:31:16 krbtgt/FNAL.GOV@FNAL.GOV
renew until 08/24/12 09:31:09, Flags: FRIA

Normal output, indicating that a forwardable, renewable, ticket exists. Check the expiration time – if the current time is past the expiration, login attempts will fail.

lqcdp4ee:~$ klist -f
klist: No credentials cache file found (ticket cache /tmp/krb5cc_5598)

If you see the above message you do not have a Kerberos ticket. Use kinit to get a ticket before attempting to login. Kerberos tickets expire after 24 hours. If you include the -r 7d switch on your kinit command line, you will receive a renewable ticket. Renewable tickets may be renewed by typing kinit -R before they expire at the end of any 24 hour period. Tickets are renewable for up to the period specified in the -r switch, to a maximum of 7 days.

Another useful switch to kinit is -f, which asks for a forwardable ticket. If you have a forwardable ticket, once you login to a Fermilab machine, say lq.fnal.gov, you can then login from lq to another machine without executing a new kinit. It is in general a bad idea to use kinit on any machine but your local system, as your password may be captured as it traverses the internet. The only time typing a kinit password is safe on a remote machine is when you are using an encrypted connection, like with ssh.

Problem: Not having an account on the target machine, or having an account on the target machine under a different username.

Solution: A permission denied error will occur if you do not have an account on the target machine, or if your username on the target machine differs from your username on your local machine. Try

ssh username@lq.fnal.gov

or

ssh -l username lq.fnal.gov

where username is your Fermilab username (the same name that you used in your kinit command). If this fails, send e-mail to lqcd-admin@fnal.gov and ask that the administrators verify that you have a valid account on the Fermilab lattice QCD systems.

Problem: Using an internet connection which has a “NAT” (Network Address Translation), such as on a home wireless router

Solution: Nearly all home routers, wired or wireless, have a “NAT” function, which results in your local system having a different local network address than what is presented to remote machines. This allows you to have multiple local machines and only one external IP address. Your local addresses will generally be something like 192.168.X.Y, or 10.X.Y.Z, when a NAT is present.

With a NAT, your ssh logins may fail with Incorrect net address. To fix this, use “address-less” tickets. First, use kdestroyto delete your current ticket. Then, use kinit with -a, -A, or -n to request an address-less ticket. The switch required varies with kerberos versions, so use man kinit on your local system to determine which of these three switches to use.

For Mac OS users, please be aware that the default behaviour on Mac OS is to supply address-less tickets, so you should also be able to simply drop the -A or -a switch entirely.

Problem: Using an SSH client which does not have Kerberos authentication enabled

Solution: Some versions of ssh will not attempt to perform kerberos authentication. In this case, you will receive a permission denied error. To enable kerberos authentication, try the following -o switch:

ssh -o “GSSAPIAuthentication yes” username@lq.fnal.gov

The quotation marks are required. If this form of SSH succeeds, you can configure your local system to always attempt to use kerberos authentication by editing either $HOME/.ssh/config or /etc/ssh/ssh_config and adding these lines:

Host *.fnal.gov
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

The GSSAPIDelegateCredentials line is necessary if you want to use X-windows clients on the remote (Fermilab) system. Note that you may also need a -X or -Y switch on your ssh command to enable X forwarding.

Источник

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