https://fedorahosted.org/sssd/ticket/924 started as a segfault ticket but we could never reproduce the crash afterwards.
As Sumit noted it might have been caused by setting the O_NONBLOCK flag twice. However, the changes Sumit proposed in the ticket still make sense because they provide much cleaner solution.
Attached are two patches:
[PATCH 1/2] Provide means of forcing TLS and GSSAPI enabled/disabled for sdap connections
This will be used to force TLS on the auth connection only and allow staying on GSSAPI-backed ID connection for the rest of the request.
[PATCH 2/2] IPA migration fixes * use the id connection for looking up the migration flag * force TLS on the password based authentication connection
On Wed, Aug 17, 2011 at 01:15:31PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/924 started as a segfault ticket but we could never reproduce the crash afterwards.
As Sumit noted it might have been caused by setting the O_NONBLOCK flag twice. However, the changes Sumit proposed in the ticket still make sense because they provide much cleaner solution.
Attached are two patches:
[PATCH 1/2] Provide means of forcing TLS and GSSAPI enabled/disabled for sdap connections
This will be used to force TLS on the auth connection only and allow staying on GSSAPI-backed ID connection for the rest of the request.
Self-nack on patch #1, it is not complete. I'll provide an updated version later.
On Wed, Aug 17, 2011 at 04:58:05PM +0200, Jakub Hrozek wrote:
On Wed, Aug 17, 2011 at 01:15:31PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/924 started as a segfault ticket but we could never reproduce the crash afterwards.
As Sumit noted it might have been caused by setting the O_NONBLOCK flag twice. However, the changes Sumit proposed in the ticket still make sense because they provide much cleaner solution.
Attached are two patches:
[PATCH 1/2] Provide means of forcing TLS and GSSAPI enabled/disabled for sdap connections
This will be used to force TLS on the auth connection only and allow staying on GSSAPI-backed ID connection for the rest of the request.
Self-nack on patch #1, it is not complete. I'll provide an updated version later.
New patches attached.
On Wed, Aug 17, 2011 at 04:58:05PM +0200, Jakub Hrozek wrote:
On Wed, Aug 17, 2011 at 01:15:31PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/924 started as a segfault ticket but we could never reproduce the crash afterwards.
As Sumit noted it might have been caused by setting the O_NONBLOCK flag twice. However, the changes Sumit proposed in the ticket still make sense because they provide much cleaner solution.
Attached are two patches:
[PATCH 1/2] Provide means of forcing TLS and GSSAPI enabled/disabled for sdap connections
This will be used to force TLS on the auth connection only and allow staying on GSSAPI-backed ID connection for the rest of the request.
Self-nack on patch #1, it is not complete. I'll provide an updated version later.
New patches attached.
The patches look fine, but I didn't manage to set up environment to test the new behavior. Nothing seems to be broken though
Jan
On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote:
On Wed, Aug 17, 2011 at 04:58:05PM +0200, Jakub Hrozek wrote:
On Wed, Aug 17, 2011 at 01:15:31PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/924 started as a segfault ticket but we could never reproduce the crash afterwards.
As Sumit noted it might have been caused by setting the O_NONBLOCK flag twice. However, the changes Sumit proposed in the ticket still make sense because they provide much cleaner solution.
Attached are two patches:
[PATCH 1/2] Provide means of forcing TLS and GSSAPI enabled/disabled for sdap connections
This will be used to force TLS on the auth connection only and allow staying on GSSAPI-backed ID connection for the rest of the request.
Self-nack on patch #1, it is not complete. I'll provide an updated version later.
New patches attached.
The patches look fine, but I didn't manage to set up environment to test the new behavior. Nothing seems to be broken though
If you have a running IPA server you can remove the krbPrincipalKey attribute from a user but keep userPassword. This should trigger sssd to run the migration code if you try to log in as this user.
HTH
bye, Sumit
Jan
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Thu, Aug 18, 2011 at 05:38:11PM +0200, Sumit Bose wrote:
On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote:
On Wed, Aug 17, 2011 at 04:58:05PM +0200, Jakub Hrozek wrote:
On Wed, Aug 17, 2011 at 01:15:31PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/924 started as a segfault ticket but we could never reproduce the crash afterwards.
As Sumit noted it might have been caused by setting the O_NONBLOCK flag twice. However, the changes Sumit proposed in the ticket still make sense because they provide much cleaner solution.
Attached are two patches:
[PATCH 1/2] Provide means of forcing TLS and GSSAPI enabled/disabled for sdap connections
This will be used to force TLS on the auth connection only and allow staying on GSSAPI-backed ID connection for the rest of the request.
Self-nack on patch #1, it is not complete. I'll provide an updated version later.
New patches attached.
The patches look fine, but I didn't manage to set up environment to test the new behavior. Nothing seems to be broken though
If you have a running IPA server you can remove the krbPrincipalKey attribute from a user but keep userPassword. This should trigger sssd to run the migration code if you try to log in as this user.
HTH
bye, Sumit
If that doesn't work for you, feel free to ping me off list and use my test environment.
On Thu, 2011-08-18 at 18:02 +0200, Jakub Hrozek wrote:
On Thu, Aug 18, 2011 at 05:38:11PM +0200, Sumit Bose wrote:
On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote:
The patches look fine, but I didn't manage to set up environment to test the new behavior. Nothing seems to be broken though
If you have a running IPA server you can remove the krbPrincipalKey attribute from a user but keep userPassword. This should trigger sssd to run the migration code if you try to log in as this user.
HTH
bye, Sumit
If that doesn't work for you, feel free to ping me off list and use my test environment.
I was trying to test this, but instead of quietly creating the kerberos password, it's prompting me to change the password. I wonder if this is related to LDAP password policy? I cannot ack this until we figure out why this is happening.
On Tue, Sep 06, 2011 at 01:48:00PM -0400, Stephen Gallagher wrote:
On Thu, 2011-08-18 at 18:02 +0200, Jakub Hrozek wrote:
On Thu, Aug 18, 2011 at 05:38:11PM +0200, Sumit Bose wrote:
On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote:
The patches look fine, but I didn't manage to set up environment to test the new behavior. Nothing seems to be broken though
If you have a running IPA server you can remove the krbPrincipalKey attribute from a user but keep userPassword. This should trigger sssd to run the migration code if you try to log in as this user.
HTH
bye, Sumit
If that doesn't work for you, feel free to ping me off list and use my test environment.
I was trying to test this, but instead of quietly creating the kerberos password, it's prompting me to change the password. I wonder if this is related to LDAP password policy? I cannot ack this until we figure out why this is happening.
Interesting, I haven't hit this issue. I have tested the migration with IPA server nightlies, today it's freeipa-server-2.99.0GITf323d81-0. My testing involved creating a bunch of users in 389-ds, migrating them to IPA with the migrate-ds script and then logging in with the LDAP password.
The login went OK and "klist" shows a ticket was granted, also "ipa user-show --all --raw" tells the Kerberos attributes were generated, including krblastsuccessfulauth.
I suggest we discuss the patches on #sssd.
On Sun, Sep 25, 2011 at 04:44:55PM +0200, Jakub Hrozek wrote:
On Tue, Sep 06, 2011 at 01:48:00PM -0400, Stephen Gallagher wrote:
On Thu, 2011-08-18 at 18:02 +0200, Jakub Hrozek wrote:
On Thu, Aug 18, 2011 at 05:38:11PM +0200, Sumit Bose wrote:
On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote:
The patches look fine, but I didn't manage to set up environment to test the new behavior. Nothing seems to be broken though
If you have a running IPA server you can remove the krbPrincipalKey attribute from a user but keep userPassword. This should trigger sssd to run the migration code if you try to log in as this user.
HTH
bye, Sumit
If that doesn't work for you, feel free to ping me off list and use my test environment.
I was trying to test this, but instead of quietly creating the kerberos password, it's prompting me to change the password. I wonder if this is related to LDAP password policy? I cannot ack this until we figure out why this is happening.
Interesting, I haven't hit this issue. I have tested the migration with IPA server nightlies, today it's freeipa-server-2.99.0GITf323d81-0. My testing involved creating a bunch of users in 389-ds, migrating them to IPA with the migrate-ds script and then logging in with the LDAP password.
The login went OK and "klist" shows a ticket was granted, also "ipa user-show --all --raw" tells the Kerberos attributes were generated, including krblastsuccessfulauth.
I suggest we discuss the patches on #sssd.
I've retested the patches again with SSSD git head + the patches on review and freeipa-server-2.1.3-2 I've performed about 20 migrations (scripted) and they went OK.
Attached are patches that are rebased on current master. Because the migration patch touches most of the ipa-auth.c file I've also fixed the debug levels there.
On Mon, 2011-11-07 at 14:34 +0100, Jakub Hrozek wrote:
On Sun, Sep 25, 2011 at 04:44:55PM +0200, Jakub Hrozek wrote:
On Tue, Sep 06, 2011 at 01:48:00PM -0400, Stephen Gallagher wrote:
On Thu, 2011-08-18 at 18:02 +0200, Jakub Hrozek wrote:
On Thu, Aug 18, 2011 at 05:38:11PM +0200, Sumit Bose wrote:
On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote:
The patches look fine, but I didn't manage to set up environment to test the new behavior. Nothing seems to be broken though
If you have a running IPA server you can remove the krbPrincipalKey attribute from a user but keep userPassword. This should trigger sssd to run the migration code if you try to log in as this user.
HTH
bye, Sumit
If that doesn't work for you, feel free to ping me off list and use my test environment.
I was trying to test this, but instead of quietly creating the kerberos password, it's prompting me to change the password. I wonder if this is related to LDAP password policy? I cannot ack this until we figure out why this is happening.
Interesting, I haven't hit this issue. I have tested the migration with IPA server nightlies, today it's freeipa-server-2.99.0GITf323d81-0. My testing involved creating a bunch of users in 389-ds, migrating them to IPA with the migrate-ds script and then logging in with the LDAP password.
The login went OK and "klist" shows a ticket was granted, also "ipa user-show --all --raw" tells the Kerberos attributes were generated, including krblastsuccessfulauth.
I suggest we discuss the patches on #sssd.
I've retested the patches again with SSSD git head + the patches on review and freeipa-server-2.1.3-2 I've performed about 20 migrations (scripted) and they went OK.
Attached are patches that are rebased on current master. Because the migration patch touches most of the ipa-auth.c file I've also fixed the debug levels there.
Nack.
Looks good for the most part, but I'm not a huge fan of the "three-way boolean" you're using for force_tls. I'd much prefer it if you just used an enum instead of a reference to a boolean.
On Tue, Nov 22, 2011 at 10:23:33AM -0500, Stephen Gallagher wrote:
On Mon, 2011-11-07 at 14:34 +0100, Jakub Hrozek wrote:
On Sun, Sep 25, 2011 at 04:44:55PM +0200, Jakub Hrozek wrote:
On Tue, Sep 06, 2011 at 01:48:00PM -0400, Stephen Gallagher wrote:
On Thu, 2011-08-18 at 18:02 +0200, Jakub Hrozek wrote:
On Thu, Aug 18, 2011 at 05:38:11PM +0200, Sumit Bose wrote:
On Thu, Aug 18, 2011 at 04:48:32PM +0200, Jan Zelený wrote: > The patches look fine, but I didn't manage to set up environment to test the > new behavior. Nothing seems to be broken though
If you have a running IPA server you can remove the krbPrincipalKey attribute from a user but keep userPassword. This should trigger sssd to run the migration code if you try to log in as this user.
HTH
bye, Sumit
If that doesn't work for you, feel free to ping me off list and use my test environment.
I was trying to test this, but instead of quietly creating the kerberos password, it's prompting me to change the password. I wonder if this is related to LDAP password policy? I cannot ack this until we figure out why this is happening.
Interesting, I haven't hit this issue. I have tested the migration with IPA server nightlies, today it's freeipa-server-2.99.0GITf323d81-0. My testing involved creating a bunch of users in 389-ds, migrating them to IPA with the migrate-ds script and then logging in with the LDAP password.
The login went OK and "klist" shows a ticket was granted, also "ipa user-show --all --raw" tells the Kerberos attributes were generated, including krblastsuccessfulauth.
I suggest we discuss the patches on #sssd.
I've retested the patches again with SSSD git head + the patches on review and freeipa-server-2.1.3-2 I've performed about 20 migrations (scripted) and they went OK.
Attached are patches that are rebased on current master. Because the migration patch touches most of the ipa-auth.c file I've also fixed the debug levels there.
Nack.
Looks good for the most part, but I'm not a huge fan of the "three-way boolean" you're using for force_tls. I'd much prefer it if you just used an enum instead of a reference to a boolean.
Done.
On Fri, 2011-11-25 at 06:55 +0100, Jakub Hrozek wrote:
On Tue, Nov 22, 2011 at 10:23:33AM -0500, Stephen Gallagher wrote:
Nack.
Looks good for the most part, but I'm not a huge fan of the "three-way boolean" you're using for force_tls. I'd much prefer it if you just used an enum instead of a reference to a boolean.
Done.
Ack
On Tue, 2011-11-29 at 14:05 -0500, Stephen Gallagher wrote:
On Fri, 2011-11-25 at 06:55 +0100, Jakub Hrozek wrote:
On Tue, Nov 22, 2011 at 10:23:33AM -0500, Stephen Gallagher wrote:
Nack.
Looks good for the most part, but I'm not a huge fan of the "three-way boolean" you're using for force_tls. I'd much prefer it if you just used an enum instead of a reference to a boolean.
Done.
Ack
Pushed to master.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jan Zelený -
Stephen Gallagher -
Sumit Bose