Tag Info

New answers tagged

0

I would do a full apt-get remove --purge and try following this tutorial. http://techpubs.spinlocksolutions.com/dklar/kerberos.html


0

In the case you outline, it should work. You can use a keytab across multiple machines as long as the clients all have some way to figure out what service principal to request a service key for. Kerberos requires that both sides of the connection figure out the service principal via some out of band means. Usually this is a convention based on the DNS name ...


0

you need kpasswd to change a kerberos password. This could help you: http://manpages.ubuntu.com/manpages/natty/man1/kpasswd.1.html


0

According to the MS-KILE documentation When clients perform a password-based initial authentication, they MUST supply the PA-ENC-TIMESTAMP pre-authentication type when they construct the initial AS request. You're Windows client apparently is not doing this. I am not pertaining to know the Windows side very well, but perhaps there are 'compatibility ...


0

Found it - the solution is to give the service account access to create its own SPNs. To do that, simply grant SELF to read and write the servicePrincipalName field: Once you do that, you'll need to restart the SQL service. DO NOT USE THE SERVICES SNAP-IN WITH CLUSTERED SQL SERVERS! The Failover Cluster service will take this as a failure and cut it ...


3

The main difference I see in your configuration compared to my live FreeIPA (on Fedora 20) is that I do not use the kernel keyring as a ticket cache. default_ccache_name = KEYRING:persistent:%{uid} My /etc/krb5.conf does not specify this at all, so the default FILE is used. Removing this should get you going again. As Matthew Ife indicates in a comment, ...


2

It sounds like you have somehow created a password policy with a minimum password life longer than the maximum password life. Remember that the maximum is specified in days while the minimum is specified in hours. If you mix these up, then it's easy to do this. To confirm it, check the existing password policy: ipa pwpolicy-find ipa pwpolicy-show ...


2

You're probably right to be at least a little concerned. Unfortunately, whether a specific application will break or not all depends on the application. But in general, it is not likely that anything will break as long as you set the SPNs properly. My main piece of advice would be: An incorrect SPN is worse than no SPN at all. The only thing I see being a ...


1

I've found the solution: Looking at an strace of the rpc.svcgssd daemon, I saw that the last file opened before the error ways the /etc/krb5.keytab. The keytab on the server was generated using kadmin with a kinit of "kadmin/admin". A kinit -k -t /etc/krb5.keytab nfs/SERVER.example.com@REALM on the SERVER resulted in a invalid password errror. So i ...


1

You are using a syntax marked as DEPRECATED in the exports(5) manpage: RPCSEC_GSS security You may use the special strings "gss/krb5", "gss/krb5i", or "gss/krb5p" to restrict access to clients using rpcsec_gss security. However, this syntax is deprecated; on linux kernels since 2.6.23, you should instead use the "sec=" export option: sec= ...


1

Jun 15 01:31:15 client rpc.gssd[24146]: WARNING: Cryptosystem internal error while getting initial ticket for principal 'nfs/CLIENT.example.com@EXAMPLE.COM' using keytab 'FILE:/etc/krb5.keytab' Can you use kinit to get a tgt using this command ( assumes mit kinit ) kinit -k -t /etc/krb5.keytab nfs/CLIENT.example.com@EXAMPLE.COM I'm guessing ...


4

You can use Kerberos authentication using the GSSAPI (Generic Security Services Application Program Interface). To achieve this you can put these settings on your sshd_config file: ChallengeResponseAuthentication yes GSSAPIKeyExchange yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes To enable PAM with password access, you should have this ...


0

If those client and kdc logs are for the same event, then it looks like you're failing due to clockskew. Make sure all involved system clocks are within 300 seconds (5 minutes) of each other, preferably by giving them all the same time source.


1

I have written code to solve your problem, but it won't work for everybody. The problem is that you have to figure out some way to extend trust to untrusted hardware. Every site will have a slightly different way to do that. I use an ssh key that is installed by our configuration management to extend trust to untrusted machines. The code I wrote is in ...


2

A generic keytab is no use at all - the Kerberos Service Principle is tied to hostname. So a generic keytab simply won't work. You don't necessarily need an NFS specific key - depending which OS version you're using. We can use HOST/full.qualified.hostname to authenticate NFS on RHEL 6+. So yes, you do need a keytab on each machine. I know that's horrible, ...



Top 50 recent answers are included