multiple realms support #312
Replies: 2 comments
-
Having a key for th principal the user's browser resolves is the correct thing, but I think what you did here is that you had an alias (this is an AD realm I guess) that the client was getting and instead of getting a keytab for that alias you created a new key in the KDC. This invalidated the tickets the clien ts had already gotten (and cached). Which resulted in the error you got later (failed to decrypt) because you also use the same kvno as the original key, therefore there is no indication the client or the server has to indicate an old ticket was used. Just wait 24 hours or erboot the clients and you should eb able to connect |
Beta Was this translation helpful? Give feedback.
-
Yes it was the cache hell :( |
Beta Was this translation helpful? Give feedback.
-
I have the problem that the server is in a different realm than the website.
For the example, the server is in realm BAR and the website is in realm FOO.BAR. On the command line it is also possible to get the appropriate ticktes:
kinit -kt /etc/website.keytab -S HTTP/@FOO.BAR host/@FOO.BAR
But with the options:
AuthType GSSAPI
AuthName ‘GSSAPI Single Sign On Login’
GssapiCredStore keytab:/etc/website.keytab
Require valid-user
only the error appears in the log:
Request ticket server HTTP/@FOO.BAR kvno 1 not found in keytab; ticket is likely out of date
If a user comes with a service ticket for HTTP/@FOO.BAR.
If I create a keytab that only has the HTTP/@FOO.BAR entry, this is what I get:
Request ticket server HTTP/@FOO.BAR kvno 1 enctype aes256-cts found in keytab but cannot decrypt ticket
What goes wrong
Beta Was this translation helpful? Give feedback.
All reactions