Re: [Freeipa-users] interesting Kerberos issue
On 5/18/15 7:47 AM, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel Going to see about installing MIT version from source on Yosemite and see what happens.. Current is 1.13.2 Will let you know ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
> On May 18, 2015, at 09:47, Nathaniel McCallum wrote: > >> On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: >> Ok, let me ask this a different way, because maybe there is a way, >> and I am just not seeing it. >> >> I have 2 datacenters with typical bastions in each. I have enabled >> OTP and that works fine via ssh. But the user has to login to both >> and opening ssh tunnels is problematic at best. >> >> Using all the creativity in this list, maybe someone knows of another >> way to have a user authenticate from a Mac where they would only have >> to do it once to get their ticket? >> >> I guess I can't think of anything, but no harm in asking. > > Without support for the OTP pre-authentication mechanism, I don't know > of any way to do this while still retaining the security properties of > Kerberos. Basically, you'll have to hand over your password to a third > party (which has OTP support). This is ill advised. > > Nathaniel Excellent point. Thanks for all the tips and advice. And of course for a great product that continues to get better. ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: > Ok, let me ask this a different way, because maybe there is a way, > and I am just not seeing it. > > I have 2 datacenters with typical bastions in each. I have enabled > OTP and that works fine via ssh. But the user has to login to both > and opening ssh tunnels is problematic at best. > > Using all the creativity in this list, maybe someone knows of another > way to have a user authenticate from a Mac where they would only have > to do it once to get their ticket? > > I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. :) ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Nathaniel McCallum wrote: > On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: > > On Mon, 18 May 2015, Janelle wrote: > > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > > > On Sun, 10 May 2015, Janelle wrote: > > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > > > Happy Star Wars Day! > > > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to > > > > > > > > > figure > > > > > > > > > out. On a > > > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > > > they get a > > > > > > > > > ticket as > > > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > > > doesn't seem to > > > > > > > > > work. > > > > > > > > > Both were enrolled the same, obviously one is > > > > > > > > > newer. > > > > > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > > > also. If I login > > > > > > > > > as > > > > > > > > > root, bypassing kerberos, and then do "kinit admin" > > > > > > > > > it > > > > > > > > > works just > > > > > > > > > fine. > > > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > > > > > kinit: Generic preauthentication failure while > > > > > > > > > getting > > > > > > > > > initial > > > > > > > > > credentials > > > > > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > > > client but not a > > > > > > > > > 6.x > > > > > > > > > client?? And yet "admin" works, no matter what. > > > > > > > > > What am > > > > > > > > > I missing > > > > > > > > > here? > > > > > > > > If I had to guess, usera is enabled for OTP-only > > > > > > > > login. > > > > > > > > Is that > > > > > > > > correct? > > > > > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. > > > > > > > > Also, > > > > > > > > the error you > > > > > > > > are getting is the result of not enabling FAST > > > > > > > > support > > > > > > > > for OTP > > > > > > > > authentication (see the -T option). > > > > > > > > > > > > > > > > Nathaniel > > > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > > > account was set for BOTH "password" and OTP. > > > > > > > Apparently setting both does nothing. Yes a user can > > > > > > > login > > > > > > > with their password-only, but trying to use kinit does > > > > > > > not > > > > > > > work. > > > > > > > > > > > > > > I am not sure I understand where the FAST support or > > > > > > > the -T > > > > > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > > > correct. > > > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > > > > > ~J > > > > > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > > > differently than in the case when it is not enabled. > > > > > > Effectively > > > > > > instead of using encrypted timestamp the password and OTP > > > > > > are > > > > > > > > > > > > sent to the server as data. But they can't be sent in > > > > > > clear. > > > > > > You > > > > > > need to encrypt the data. To encrypt it you need another > > > > > > key > > > > > > - > > > > > > the host key. The encryption of the data in this context > > > > > > is > > > > > > called tunneling . FAST is the Kerberos protocol feature > > > > > > to > > > > > > provide tunneling of the data sent over the wire. To use > > > > > > FAST > > > > > > > > > > > > one needs to use -T on the kinit command line. > > > > > > Does this help? > > > > > > > > > > > It helps -- thank you. > > > > > > > > > > Now allow me to add a little more fun, and there may not be > > > > > a > > > > > solution. > > > > > > From OS X (Yosemite) I am able to "kinit --kdc > > > > > > -hostname=IPA > > > > > > -server > > > > > principal" and it works, gives me a ticket, and if I > > > > > attempt to > > > > > > > > > > login to the web interface, since I already have my ticket > > > > > - > > > > > boom, > > > > > works fine. > > > > > > > > > > Now, I enable 2FA and setup a token and change my account > > > > > to > > > > > OTP > > > > > (with TOTP). But as previously discussed, can't seem to > > > > > specify a > > > > > -T option from OS X. > > > > > > > > > > I know this sounds tricky -- Any ideas? > > > > Use > > > > kinit --fast-armor-cache /path/to/ccache to specify already > > > > existing ccache to armor the FAST processing. > > > > > > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 > > > > at > > > > least. > > > > You can check version number by running 'kinit --version'. > > > Aha, so thee default on OS X Yosemite is > > > > > > $ kinit --version > > > kinit
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote: > On Mon, 18 May 2015, Nathaniel McCallum wrote: > > On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: > > > On Mon, 18 May 2015, Janelle wrote: > > > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > > > > On Sun, 10 May 2015, Janelle wrote: > > > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > > > > Happy Star Wars Day! > > > > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to > > > > > > > > > > figure > > > > > > > > > > out. On a > > > > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > > > > they get a > > > > > > > > > > ticket as > > > > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > > > > doesn't seem to > > > > > > > > > > work. > > > > > > > > > > Both were enrolled the same, obviously one is > > > > > > > > > > newer. > > > > > > > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > > > > also. If I login > > > > > > > > > > as > > > > > > > > > > root, bypassing kerberos, and then do "kinit admin" > > > > > > > > > > it > > > > > > > > > > works just > > > > > > > > > > fine. > > > > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > > > > > > > kinit: Generic preauthentication failure while > > > > > > > > > > getting > > > > > > > > > > initial > > > > > > > > > > credentials > > > > > > > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > > > > client but not a > > > > > > > > > > 6.x > > > > > > > > > > client?? And yet "admin" works, no matter what. > > > > > > > > > > What am > > > > > > > > > > I missing > > > > > > > > > > here? > > > > > > > > > If I had to guess, usera is enabled for OTP-only > > > > > > > > > login. > > > > > > > > > Is that > > > > > > > > > correct? > > > > > > > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. > > > > > > > > > Also, > > > > > > > > > the error you > > > > > > > > > are getting is the result of not enabling FAST > > > > > > > > > support > > > > > > > > > for OTP > > > > > > > > > authentication (see the -T option). > > > > > > > > > > > > > > > > > > Nathaniel > > > > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > > > > account was set for BOTH "password" and OTP. > > > > > > > > Apparently setting both does nothing. Yes a user can > > > > > > > > login > > > > > > > > with their password-only, but trying to use kinit does > > > > > > > > not > > > > > > > > work. > > > > > > > > > > > > > > > > I am not sure I understand where the FAST support or > > > > > > > > the -T > > > > > > > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > > > > correct. > > > > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > > > > > > > ~J > > > > > > > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > > > > differently than in the case when it is not enabled. > > > > > > > Effectively > > > > > > > instead of using encrypted timestamp the password and OTP > > > > > > > are > > > > > > > > > > > > > > sent to the server as data. But they can't be sent in > > > > > > > clear. > > > > > > > You > > > > > > > need to encrypt the data. To encrypt it you need another > > > > > > > key > > > > > > > - > > > > > > > the host key. The encryption of the data in this context > > > > > > > is > > > > > > > called tunneling . FAST is the Kerberos protocol feature > > > > > > > to > > > > > > > provide tunneling of the data sent over the wire. To use > > > > > > > FAST > > > > > > > > > > > > > > one needs to use -T on the kinit command line. > > > > > > > Does this help? > > > > > > > > > > > > > It helps -- thank you. > > > > > > > > > > > > Now allow me to add a little more fun, and there may not be > > > > > > a > > > > > > solution. > > > > > > > From OS X (Yosemite) I am able to "kinit --kdc > > > > > > > -hostname=IPA > > > > > > > -server > > > > > > principal" and it works, gives me a ticket, and if I > > > > > > attempt to > > > > > > > > > > > > login to the web interface, since I already have my ticket > > > > > > - > > > > > > boom, > > > > > > works fine. > > > > > > > > > > > > Now, I enable 2FA and setup a token and change my account > > > > > > to > > > > > > OTP > > > > > > (with TOTP). But as previously discussed, can't seem to > > > > > > specify a > > > > > > -T option from OS X. > > > > > > > > > > > > I know this sounds tricky -- Any ideas? > > > > > Use > > > > > kinit --fast-armor-cache /path/to/ccache to specify already > > > > > existing ccache to armor the FAST processing. > > > > > > > > > >
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Janelle wrote: > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > On Sun, 10 May 2015, Janelle wrote: > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > Happy Star Wars Day! > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to figure > > > > > > > out. On a > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > they get a > > > > > > > ticket as > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > doesn't seem to > > > > > > > work. > > > > > > > Both were enrolled the same, obviously one is newer. > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > also. If I login > > > > > > > as > > > > > > > root, bypassing kerberos, and then do "kinit admin" it > > > > > > > works just > > > > > > > fine. > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > kinit: Generic preauthentication failure while getting > > > > > > > initial > > > > > > > credentials > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > client but not a > > > > > > > 6.x > > > > > > > client?? And yet "admin" works, no matter what. What am > > > > > > > I missing > > > > > > > here? > > > > > > If I had to guess, usera is enabled for OTP-only login. > > > > > > Is that > > > > > > correct? > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. Also, > > > > > > the error you > > > > > > are getting is the result of not enabling FAST support > > > > > > for OTP > > > > > > authentication (see the -T option). > > > > > > > > > > > > Nathaniel > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > account was set for BOTH "password" and OTP. > > > > > Apparently setting both does nothing. Yes a user can login > > > > > with their password-only, but trying to use kinit does not > > > > > work. > > > > > > > > > > I am not sure I understand where the FAST support or the -T > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > correct. > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > ~J > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > differently than in the case when it is not enabled. > > > > Effectively > > > > instead of using encrypted timestamp the password and OTP are > > > > > > > > sent to the server as data. But they can't be sent in clear. > > > > You > > > > need to encrypt the data. To encrypt it you need another key > > > > - > > > > the host key. The encryption of the data in this context is > > > > called tunneling . FAST is the Kerberos protocol feature to > > > > provide tunneling of the data sent over the wire. To use FAST > > > > > > > > one needs to use -T on the kinit command line. > > > > Does this help? > > > > > > > It helps -- thank you. > > > > > > Now allow me to add a little more fun, and there may not be a > > > solution. > > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA > > > > -server > > > principal" and it works, gives me a ticket, and if I attempt to > > > > > > login to the web interface, since I already have my ticket - > > > boom, > > > works fine. > > > > > > Now, I enable 2FA and setup a token and change my account to > > > OTP > > > (with TOTP). But as previously discussed, can't seem to > > > specify a > > > -T option from OS X. > > > > > > I know this sounds tricky -- Any ideas? > > Use > > kinit --fast-armor-cache /path/to/ccache to specify already > > existing ccache to armor the FAST processing. > > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at > > least. > > You can check version number by running 'kinit --version'. > Aha, so thee default on OS X Yosemite is > > $ kinit --version > kinit (Heimdal 1.5.1apple1) > > so this won't work? Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( The support is since 1.6rc2, it uses the Richards' draft (draft-richards-otp-kerberos-01.txt) as a base and handles preauth but I don't think anything but login and ftpd supports passing the OTP token. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: > On Mon, 18 May 2015, Janelle wrote: > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > > On Sun, 10 May 2015, Janelle wrote: > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > > Happy Star Wars Day! > > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to figure > > > > > > > > out. On a > > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > > they get a > > > > > > > > ticket as > > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > > doesn't seem to > > > > > > > > work. > > > > > > > > Both were enrolled the same, obviously one is newer. > > > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > > also. If I login > > > > > > > > as > > > > > > > > root, bypassing kerberos, and then do "kinit admin" it > > > > > > > > works just > > > > > > > > fine. > > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > > > kinit: Generic preauthentication failure while getting > > > > > > > > initial > > > > > > > > credentials > > > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > > client but not a > > > > > > > > 6.x > > > > > > > > client?? And yet "admin" works, no matter what. What am > > > > > > > > I missing > > > > > > > > here? > > > > > > > If I had to guess, usera is enabled for OTP-only login. > > > > > > > Is that > > > > > > > correct? > > > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. Also, > > > > > > > the error you > > > > > > > are getting is the result of not enabling FAST support > > > > > > > for OTP > > > > > > > authentication (see the -T option). > > > > > > > > > > > > > > Nathaniel > > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > > account was set for BOTH "password" and OTP. > > > > > > Apparently setting both does nothing. Yes a user can login > > > > > > with their password-only, but trying to use kinit does not > > > > > > work. > > > > > > > > > > > > I am not sure I understand where the FAST support or the -T > > > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > > correct. > > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > > > ~J > > > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > > differently than in the case when it is not enabled. > > > > > Effectively > > > > > instead of using encrypted timestamp the password and OTP are > > > > > > > > > > sent to the server as data. But they can't be sent in clear. > > > > > You > > > > > need to encrypt the data. To encrypt it you need another key > > > > > - > > > > > the host key. The encryption of the data in this context is > > > > > called tunneling . FAST is the Kerberos protocol feature to > > > > > provide tunneling of the data sent over the wire. To use FAST > > > > > > > > > > one needs to use -T on the kinit command line. > > > > > Does this help? > > > > > > > > > It helps -- thank you. > > > > > > > > Now allow me to add a little more fun, and there may not be a > > > > solution. > > > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA > > > > > -server > > > > principal" and it works, gives me a ticket, and if I attempt to > > > > > > > > login to the web interface, since I already have my ticket - > > > > boom, > > > > works fine. > > > > > > > > Now, I enable 2FA and setup a token and change my account to > > > > OTP > > > > (with TOTP). But as previously discussed, can't seem to > > > > specify a > > > > -T option from OS X. > > > > > > > > I know this sounds tricky -- Any ideas? > > > Use > > > kinit --fast-armor-cache /path/to/ccache to specify already > > > existing ccache to armor the FAST processing. > > > > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at > > > least. > > > You can check version number by running 'kinit --version'. > > Aha, so thee default on OS X Yosemite is > > > > $ kinit --version > > kinit (Heimdal 1.5.1apple1) > > > > so this won't work? > Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( Nathaniel -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 18 May 2015, Janelle wrote: On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server principal" and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? Yes, you have to have the feature in your Kerberos library. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server principal" and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? ~J PS - sorry for the questions, still trying to wrap my head around how to get OTP working from a term session so you can get your ticket and then login to all the hosts you need without reauthenticating. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server principal" and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server principal" and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Thank you Janelle -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 05/04/2015 09:22 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Apparently I am not being clear. The user account can login all over the place with no problems -- RHEL 7.1 or 6.6. HOWEVER, on 7.1, a login provides a direct tgt, but no matter what you do on any other host using kinit (after logging in with an SSH key perhaps or as another user) and even know the password, you get this error. Again, logging in with the password, not OTP, works just fine. Confusing, ~J Do you get any SELinux AVCs? May be it is an issue of the ticket cache permissions/labels? -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Apparently I am not being clear. The user account can login all over the place with no problems -- RHEL 7.1 or 6.6. HOWEVER, on 7.1, a login provides a direct tgt, but no matter what you do on any other host using kinit (after logging in with an SSH key perhaps or as another user) and even know the password, you get this error. Again, logging in with the password, not OTP, works just fine. Confusing, ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > Happy Star Wars Day! > May the Fourth be with you! > > So I have a strange Kerberos problem trying to figure out. On a > CLIENT, (CentOS 7.1) if I login to account "usera" they get a > ticket as > expected. However, if I login to a 6.6 client, it doesn't seem to > work. > Both were enrolled the same, obviously one is newer. > > Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login > as > root, bypassing kerberos, and then do "kinit admin" it works just > fine. > But if I do "kinit usera" I get: > > kinit: Generic preauthentication failure while getting initial > credentials > > Which makes no sense. The account works with a 7.1 client but not a > 6.x > client?? And yet "admin" works, no matter what. What am I missing > here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 5/4/15 1:02 PM, Simo Sorce wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? Have you recently changed the user password ? If so this symptom may indicate you are having replication issues between your servers, and one of the client is hitting the server that didn't get the keys replicated to it. Simo. None of the above -- All the servers are replicated. The user account (a test account) has not changed PW in weeks and works everywhere else. I nee to increase some logging. I guess the strange part is as mentioned -- it works if you login directly to the 7.1 client, no matter which server it is pointed at. ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > Happy Star Wars Day! > May the Fourth be with you! > > So I have a strange Kerberos problem trying to figure out. On a > CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as > expected. However, if I login to a 6.6 client, it doesn't seem to work. > Both were enrolled the same, obviously one is newer. > > Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as > root, bypassing kerberos, and then do "kinit admin" it works just fine. > But if I do "kinit usera" I get: > > kinit: Generic preauthentication failure while getting initial credentials > > Which makes no sense. The account works with a 7.1 client but not a 6.x > client?? And yet "admin" works, no matter what. What am I missing here? Have you recently changed the user password ? If so this symptom may indicate you are having replication issues between your servers, and one of the client is hitting the server that didn't get the keys replicated to it. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On 05/04/2015 11:49 AM, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? ~J This is really strange. What does happen on the server when you try kinit usera? Have you checked the KDC log? Look at the usera entry, may be there is some strange attribute there that causes this failure. Compare with admin entry. May be it will shed some light. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
