Can you obtain a ticket for your principal on your client system either as part of the standard login process or manually (kinit, MIT Kerberos for Windows)?
Does the server has a kerberos principal or can you give it one? It should be of the form host/server.example.com@EXAMPLE.COM.
Is GSSAPI authentication enabled on your client?
Does your client ...
The sssd daemon acts as the spider in the web, controlling the login process and more. The login program communicates with the configured pam and nss modules, which in this case are provided by the SSSD package. These modules communicate with the corresponding SSSD responders, which in turn talk to the SSSD Monitor. SSSD looks up the user in the LDAP ...
I would look into using pam-krb5.
On Debian and Ubuntu, it should be apt-get install libpam-krb5.
The PAM configuration would look something like:
auth required pam_unix.so
auth optional pam_krb5.so try_first_pass
auth required pam_unix.so
auth optional pam_krb5.so use_first_pass
It takes the password you used to ...
Kerberos will work only if you authenticate to Kerberos-enabled server by password. You can:
set up kerberos trust for the incoming user if the user is already authenticated by known realm;
enable GSSAPI forwarding of credentials on ssh client and server ('ssh -K', GSSAPIAuthentication for sshd), this would work if server and client belongs to the same ...
Java doesn't necessarily support all encryption types supported by (presumably MIT) kinit (libkrb5).
It's possible to configure the encryption types used by libkrb5 in the krb5.conf file (usually in /etc). For example (not necessarily the most secure ones):
# default_tgs_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
The 4-step method is correct (there also are Kerberos SRV records in DNS that are even more elegant and are present in every Active Directory). I use this all the time, and have been advocating this above pubkey methods for , mostly security and control-related reasons.
That said, this only gives interactive login, although it can be quasi-interactive once ...
uid=tupac,ou=people,dc=maytacapac,dc=inc looks wrong, as most (okay, all except this one) LDAP-provided group memberships I've seen do not include a LDAP DN, and instead just the username, so I would expect to instead see adminsLinux:*:3000:tupac.
Thanks to Mark Plotnick I was able to identify and fix the issue.
The problem is the interaction between the AFS file system used by the server and Kerberos handling the authentication. The same issue was brought up in this question on SO.
Basically what is happening is that when I ssh into the server, Kerberos gives the authentication token to the session....
I stumble on this by accident. I realize you asked this ages ago, but wanted to chime in. The behavior you are seeing is a result of the way the Linux client deals with credentials. Once it finds a working credential, it caches it in memory. Even after you kdestroy, your (still valid) credentials are cached by the client.
Quoting from http://www.citi.umich....
For future googlers: I just had a very similar problem on RHEL7.
authconfig had been run with '--enablesssd --enablesssdauth --enablemkhomedir --update'
sssd had been (re)started
oddjob-mkhomedir installed and oddjobd had been (re)started
Still wasn't creating directories when logging in with an LDAP user.
Turned out that when I restarted dbus ...
I've seen similar issues with gdm.
The problem is not directly related to SDDM, it is related to a combination of the fact that LDAP users are unknown until we have access to the LDAP server, the fact that systemd was made the default init system in Debian Jessie (which adds massive parallellisation to startup) and the fact that, by default, there is no ...
This issue seems likely to be a problem with the installation of a Active Directory (AD) integration product for authentication called LikeWise. This product is no longer available, to my knowledge.
You can read more about it her in this articled titled: How to join Linux server into Active Directory on SBS 2008 network. It's also listed here in the ...
use a cron job with kinit and the keytab (man kinit, look at options -k, eventually -t if you use other keytab than the host's).
Raspian is debian based, I believe, so maybe you can use the k5start package that should automate this for you.
What Appears To Be The Problem
The tutorial completely ignored many needed elements in fact (sssd, pam, etc), probably it is not the point of it as the focus appears to be RHEL exams. I'm still a little lost on all tools involved in this task as I'm not a sysadmin (a lot of question for another moment), but I've managed to get it working. Thanks to ...
The issue was actually a difference in /etc/krb5.conf I managed to overlook - my new server had
dns_canonicalize_hostname = false
set, which - exactly as you might expect - caused the hostname to not be canonicalized to the FQDN. According to the man page, this option defaults to "true," so I'm not exactly sure why it was changed. The file has the comment
I don't believe there's any current support for this in any of the Kerberos PAM modules that I'm aware of. I can see how it could be implemented, though; there's nothing inherently impossible about it. Basically, pam_krb5 would need to gain code to open a ticket cache pointed to by the current KRB5CCNAME, iterate through it, and copy each ticket found into ...
How did you prove this exactly?
If you use net ads join, Samba does in fact create a standard principal for a computer object. It just does not export this to a system keytab file, unless configured explicitly.
Check out the "kerberos method" parameter in smb.conf(5) (for samba 4.0; not sure about the older versions).
If you do not need to expose any ...
I found the answer and it's a very strange one!
I used the getprinc command within kadmin to obtain the attributes of both the problem principal and a principal that was created without +needchange and that was authenticating correctly.
The difference was that the principal authenticating correctly had the REQUIRES_PRE_AUTH attribute set while the problem ...
Kerberos credentials expire after a set amount of time. This is set up by the site admins, typical is about 24hrs.
Your real problem is that your home directory is likely in AFS which is a distributed filesystem that uses kerberos for authentication.
What you need to do to regain file access is to aquire a new kerberos ticket and AFS token. ( tokens are ...
Edit : Systemd 216-3 is now in the core package, there shouldn't be any bugs now
The fact that you can't log in as root isn't related to the systemd problem. https://bugs.archlinux.org/task/41711 systemd had a problem identifying a first boot and enabled every service; currently, it is only fixed in the [testing] packages.
I recommend the first solution, ...
enabling iptables (touch /etc/iptables/...) with an empty ruleset is really a bad idea
you should reinstall your system; the bug (enabling of unrequested services - there are much more than iptables) is fixed in ARCH: https://bugs.archlinux.org/task/41711
Edit: maybe you should wait with reinstallation until systemd (https://www.archlinux.org/packages/core/...
I always use klist instead to list the contents of keytab files out instead of ktutil.
Example #1 - klist
$ klist -kt /etc/somedir/conf/some.keytab
Keytab name: FILE:/etc/somedir/conf/some.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
5 08/25/15 11:18:35 app/host1.dom.local@TD.COM
I would look at few things
- is oddjobd running?
- any messages related to this or PAM in authlog, messages
- is SElinux enabled or enforced? check audit log for any AVC denial messages
Looking again at your sssd.conf, you may want to move override_homedir into the DOMAIN section, otherwise sssd seems to get home directory information from ldap.
The dirty solution is to update tmux's value for $KRB5CCNAME. First,
run this outside tmux:
$ echo $KRB5CCNAME
Then, inside tmux, you need to export that new value:
$ export KRB5CCNAME='FILE:/tmp/krb5cc_201108_XXXXXX'
Now, tmux has your new credentials.
Most likely the enctypes your kerberos KDC has for your principal isn't something that kinit on your ubuntu system is set up to use.
You might need to edit your /etc/krb5.conf to set default_tkt_enctypes and default_tgs_enctypes in the [libdefaults] section to be the appropriate value. I know a lot of older, out of date KDCs will still use 'des-cbc-crc', ...