Re: [Freeipa-users] Force ticket type to des3-cbc-sha1
This is just for testing, ideally for one user but will take anything ;-) On 10/09/14 18:16, Rob Crittenden wrote: Darran Lofthouse wrote: Hi there, Hi there any quick way to force the ticket type obtained by kinit to des3-cbc-sha1? For all users everywhere, on a particular host, or for a particular application? rob -- 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] Force ticket type to des3-cbc-sha1
Actually ignore me for a minute, I may be looking at this from the wrong side !! On 10/09/14 18:24, Darran Lofthouse wrote: This is just for testing, ideally for one user but will take anything ;-) On 10/09/14 18:16, Rob Crittenden wrote: Darran Lofthouse wrote: Hi there, Hi there any quick way to force the ticket type obtained by kinit to des3-cbc-sha1? For all users everywhere, on a particular host, or for a particular application? rob -- 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] Force ticket type to des3-cbc-sha1
Thanks, was looking at the wrong side - just needed to re-export the keytab for my service using des3-cbc-sha1 instead. On 10/09/14 18:31, Darran Lofthouse wrote: Actually ignore me for a minute, I may be looking at this from the wrong side !! On 10/09/14 18:24, Darran Lofthouse wrote: This is just for testing, ideally for one user but will take anything ;-) On 10/09/14 18:16, Rob Crittenden wrote: Darran Lofthouse wrote: Hi there, Hi there any quick way to force the ticket type obtained by kinit to des3-cbc-sha1? For all users everywhere, on a particular host, or for a particular application? rob -- 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] ipa-getkeytab and mandatory password change
On 06/19/2012 07:12 PM, Stephen Ingram wrote: On Tue, Jun 19, 2012 at 9:55 AM, Simo Sorce s...@redhat.com wrote: On Tue, 2012-06-19 at 09:15 -0700, Stephen Ingram wrote: On Tue, Jun 19, 2012 at 2:54 AM, Dmitri Pal d...@redhat.com wrote: On 06/18/2012 11:58 AM, Darran Lofthouse wrote: Just experienced some weird behaviour on my Fedora 17 installation, just wanted to check if this was expected. I have the default config that requires a user to change their password the first time they run kinit. However I created a user and immediately used ipa-getkeytab as this user will be a non-interactive process, despite the ipa-getkeytab resetting the secret for the user the first attempt at authentication failed as the user was still told to change their password. I do not think we have anticipated this use. The ipa-getkeytab is designed for the host and services keytabs not for users. I suggest that use a service principal rather than a user principal to run those jobs. You can also file an RFE to allow keytabs for users if you think that services would not work for you. My expectation would have been that any update to the secret should meet the requirement for the user to change their password. Darren- I'm not sure if you went further with this, but if you do change the password through other means, you then will be able to get a copy of the keytab for the user with ipa-getkeytab. I tried it out because the thought of not being able to get a keytab for a user was concerning. I agree that the service keytabs make more sense for these instances (I was also told this by Simo in another thread), but I keep being told by the application people that I need to use a user principal, which, thankfully works. Ask them why, I am curious about the requirement. What I was trying to achieve was a single Java process obtaining it's own ticket before it connected to a service that was identified by a service principal mapping. In this scenario the client process is just as non-interactive as the server process so both sides were being configured with a keytab. Obtaining the keytab works fine and the client can use it - the only part that was a surprise was that the requirement for the client to change their password remained even though it was now redundant as a keytab had been generated. I'm still waiting for responses. The only thing I've been told thus far is that since there are multiple processes authenticating to their respective servers, it might be difficult to direct each to the proper credential cache. If you use one user to auth to each server process then there is only one credential cache. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa-getkeytab and mandatory password change
Just experienced some weird behaviour on my Fedora 17 installation, just wanted to check if this was expected. I have the default config that requires a user to change their password the first time they run kinit. However I created a user and immediately used ipa-getkeytab as this user will be a non-interactive process, despite the ipa-getkeytab resetting the secret for the user the first attempt at authentication failed as the user was still told to change their password. My expectation would have been that any update to the secret should meet the requirement for the user to change their password. Regards, Darran Lofthouse. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Authentication Failure from Java - LoginException PREAUTH_FAILED - Partly Solved
Just sending a quick update as I am able to move on from this issue now. I have now moved over to Fedora 17 with the version of FreeIPA currently packaged for Fedora 17 and after getting over the installation hang I can confirm that my Java client is authenticating without issue against the newly installed server. At this point I don't know what is causing the failure on the previous version but I am suspecting some incompatibility with the messages generated with Java. Regards, Darran Lofthouse. On 05/31/2012 10:28 AM, Darran Lofthouse wrote: My apologies if this has already been discussed somewhere, I have tried a number of searches to see if this is either a known issue or common error on the client side but so far only found references to Java issues that should have been resolved a long time ago. I have a Red Hat server running in Amazon EC2 with IPA ipa-server-2.1.3-9.el6.x86_64 installed - I have an admin user and a test_user defined. From my local machine using kinit works without error. I have developed a test Java client to make use of the Krb5LoginModule, I am currently debugging further but thought I would mail this in parallel in case I am missing something obvious but I keep getting the failure that is at the bottom of this message. This failure is reported when using java-1.7.0-openjdk-1.7.0.3.x86_64 - however I have also tried using various Oracle JDKs, both 6 and 7. I know the password is correct as verified using kinit, also if I use jdk1.6.0_30 AND set the system property for Kerberos debugging to true on the client it works. The only difference I currently see between the failure scenario and success scenario is that for success rc4-hmac is selected for the PA-ENC-TIMESTAMP for the failure scenario here aes256-cts-hmac-sha1-96 is selected instead. For the work I am currently using IPA for I could just force the use of rc4-hmac but would really like to get to the bottom of the cause of this. Looking forward to any ideas. Regards, Darran Lofthouse. Exception in thread main javax.security.auth.login.LoginException: Integrity check on decrypted field failed (31) - PREAUTH_FAILED at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:759) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:580) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) at javax.security.auth.login.LoginContext$5.run(LoginContext.java:721) at javax.security.auth.login.LoginContext$5.run(LoginContext.java:719) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:718) at javax.security.auth.login.LoginContext.login(LoginContext.java:590) at com.darranl.as.sasl.gssapi.KerberosLoginUtil.login(KerberosLoginUtil.java:50) at com.darranl.as.sasl.gssapi.KerberosLoginUtil.main(KerberosLoginUtil.java:136) Caused by: KrbException: Integrity check on decrypted field failed (31) - PREAUTH_FAILED at sun.security.krb5.KrbAsRep.init(KrbAsRep.java:82) at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316) at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:721) ... 14 more Caused by: KrbException: Identifier doesn't match expected value (906) at sun.security.krb5.internal.KDCRep.init(KDCRep.java:143) at sun.security.krb5.internal.ASRep.init(ASRep.java:65) at sun.security.krb5.internal.ASRep.init(ASRep.java:60) at sun.security.krb5.KrbAsRep.init(KrbAsRep.java:60) ... 17 more ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installation Hang on Fedora 17
I have recently been having problems on RHEL so I thought I would try installing a Fedora 17 installation to test this but appear to be running into further problems. Everything appears to go well with the installation until it stops on the following line: - Applying LDAP updates The last two lines in the log are: - 2012-06-11T15:33:05Z DEBUG cn: Write IPA Configuration 2012-06-11T15:33:05Z DEBUG description: Write IPA Configuration I have seen reported that there was a problem in the F17 Beta release where a downgrade of '389-ds-base' would address this but this does not seem to be an option now. Does anyone know the underlying cause of the hang? Maybe there is something I can do to address this. Regards, Darran Lofthouse. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Authentication Failure from Java - LoginException PREAUTH_FAILED
My apologies if this has already been discussed somewhere, I have tried a number of searches to see if this is either a known issue or common error on the client side but so far only found references to Java issues that should have been resolved a long time ago. I have a Red Hat server running in Amazon EC2 with IPA ipa-server-2.1.3-9.el6.x86_64 installed - I have an admin user and a test_user defined. From my local machine using kinit works without error. I have developed a test Java client to make use of the Krb5LoginModule, I am currently debugging further but thought I would mail this in parallel in case I am missing something obvious but I keep getting the failure that is at the bottom of this message. This failure is reported when using java-1.7.0-openjdk-1.7.0.3.x86_64 - however I have also tried using various Oracle JDKs, both 6 and 7. I know the password is correct as verified using kinit, also if I use jdk1.6.0_30 AND set the system property for Kerberos debugging to true on the client it works. The only difference I currently see between the failure scenario and success scenario is that for success rc4-hmac is selected for the PA-ENC-TIMESTAMP for the failure scenario here aes256-cts-hmac-sha1-96 is selected instead. For the work I am currently using IPA for I could just force the use of rc4-hmac but would really like to get to the bottom of the cause of this. Looking forward to any ideas. Regards, Darran Lofthouse. Exception in thread main javax.security.auth.login.LoginException: Integrity check on decrypted field failed (31) - PREAUTH_FAILED at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:759) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:580) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) at javax.security.auth.login.LoginContext$5.run(LoginContext.java:721) at javax.security.auth.login.LoginContext$5.run(LoginContext.java:719) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:718) at javax.security.auth.login.LoginContext.login(LoginContext.java:590) at com.darranl.as.sasl.gssapi.KerberosLoginUtil.login(KerberosLoginUtil.java:50) at com.darranl.as.sasl.gssapi.KerberosLoginUtil.main(KerberosLoginUtil.java:136) Caused by: KrbException: Integrity check on decrypted field failed (31) - PREAUTH_FAILED at sun.security.krb5.KrbAsRep.init(KrbAsRep.java:82) at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316) at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:721) ... 14 more Caused by: KrbException: Identifier doesn't match expected value (906) at sun.security.krb5.internal.KDCRep.init(KDCRep.java:143) at sun.security.krb5.internal.ASRep.init(ASRep.java:65) at sun.security.krb5.internal.ASRep.init(ASRep.java:60) at sun.security.krb5.KrbAsRep.init(KrbAsRep.java:60) ... 17 more ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
