Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
Full disclosure: I was the one who redirected Mathieu to you, Honza :-)
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
I think as a first step, it would be nice to put debug_level=8 into the [ssh] section of the sssd.conf file, restart the SSSD and then attach the ssh responder logs (/var/log/sssd/sssd_nss.log).
Also the sssd.conf (sanitized if needed) would come handy.
2013/3/19 Jakub Hrozek jhrozek@redhat.com
On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages)
configured
on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing
seems
to get out of it...
Full disclosure: I was the one who redirected Mathieu to you, Honza :-)
If any of you had informations regarding that, it'd be greatly
appreciated.,
Mathieu.
I think as a first step, it would be nice to put debug_level=8 into the [ssh] section of the sssd.conf file, restart the SSSD and then attach the ssh responder logs (/var/log/sssd/sssd_nss.log).
Also the sssd.conf (sanitized if needed) would come handy.
The sssd.conf is simple enough (I attached a cleaned version, I only changed the domain name and dc=* records for "office", anyway, authentication and getent are working just fine, so the connection to my LDAP is not the issue).
Regarding the logs, with debug_level 10, I can see nothing related to ssh in sssd_nss.log. However, I have the following lines in sssd_office.log:
(Tue Mar 19 14:21:11 2013) [sssd[be[office]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [mlemoine].
(Got one per user every ten seconds)
However, sshPublicKey is in my user (mlemoine), which is also the only user with an sshPublicKey attribute.
Did I miss something?
Thanks for your help.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/19/2013 02:27 PM, Mathieu Lemoine wrote:
According to your configuration, SSSD is connecting anonymously to the LDAP server (you don't have a bind user or password configured). Can you install the openldap-clients package (or whatever its equivalent is for Ubuntu) and run the following command:
ldapsearch -x -H ldap://ldap.office \ -b cn=users,dc=ldap,dc=office \ "(uid=mlemoine)" \ sshPublicKey
My guess is that the sshPublicKey attribute will not be returned because the anonymous user is unlikely to have access to it. The solution to this would be to set the bind user for LDAP to an account that does have this privilege (or change the ACLs on the server so that the anonymous user can read that attribute.
If it *is* returned, then there's a different problem.
On 19.3.2013 19:27, Mathieu Lemoine wrote:
However, sshPublicKey is in my user (mlemoine), which is also the only user with an sshPublicKey attribute.
Did I miss something?
This perhaps: https://fedorahosted.org/sssd/ticket/1560
Honza
On Tue, Mar 19, 2013 at 07:15:21PM +0100, Jakub Hrozek wrote:
On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
Full disclosure: I was the one who redirected Mathieu to you, Honza :-)
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
I think as a first step, it would be nice to put debug_level=8 into the [ssh] section of the sssd.conf file, restart the SSSD and then attach the ssh responder logs (/var/log/sssd/sssd_nss.log).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry, this is a copy-n-paste error. The *ssh* responder log is located at: /var/log/sssd/sssd_ssh.log
The path I copied was the *nss* responder log. Sorry again.
2013/3/19 Jakub Hrozek jhrozek@redhat.com
On Tue, Mar 19, 2013 at 07:15:21PM +0100, Jakub Hrozek wrote:
On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages)
configured
on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public
keys".
An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing
seems
to get out of it...
Full disclosure: I was the one who redirected Mathieu to you, Honza :-)
If any of you had informations regarding that, it'd be greatly
appreciated.,
Mathieu.
I think as a first step, it would be nice to put debug_level=8 into the [ssh] section of the sssd.conf file, restart the SSSD and then attach the ssh responder logs (/var/log/sssd/sssd_nss.log).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^Sorry, this is a copy-n-paste error. The *ssh* responder log is located at: /var/log/sssd/sssd_ssh.log
The path I copied was the *nss* responder log. Sorry again.
Ok, so first point, I didn't know I needed a sss responder for ssh (not mentionned anywhere as far as I know). Thanks for this. I added ", ssh" to the "services" line and restarted sssd.
sss_ssh.log stays hopelessly empty even with debug_level 10 and I still have the sshPublicKey is not available in sss_office.log
However sss_ssh_authorizedkeys now doesn't return any error, just a big nothing...
Attached is the ldif of my user (I removed any sensitive information, anyway, the entry has been fetched using anonymous access, so passwords and such has been left aside.
On 03/19/2013 08:05 PM, Mathieu Lemoine wrote:
2013/3/19 Jakub Hrozek <jhrozek@redhat.com mailto:jhrozek@redhat.com>
On Tue, Mar 19, 2013 at 07:15:21PM +0100, Jakub Hrozek wrote: > On Tue, Mar 19, 2013 at 01:56:20PM -0400, Mathieu Lemoine wrote: > > Hello, > > > > I have sssd 1.9.4 (from > > https://launchpad.net/~nicholas-hatch/+archive/auth/+packages) configured > > on an OpenLDAP server. > > getent passwd, getent group, authentication and cache is working great. > > > > My issue now lies with the SSH public key. > > > > My user has the ldapPublicKey objectClass, and the key is in the > > sshPublicKey attribute. > > > > sss_ssh_authorizedkeys is still returning "Error looking up public keys". > > An inquiry on the #sssd chan directed me to this mailing-list and more > > precisely to jcholast, I tried to check out the commits, but nothing seems > > to get out of it... > > Full disclosure: I was the one who redirected Mathieu to you, Honza :-) > > > > > If any of you had informations regarding that, it'd be greatly appreciated., > > Mathieu. > > I think as a first step, it would be nice to put debug_level=8 into the > [ssh] section of the sssd.conf file, restart the SSSD and then attach > the ssh responder logs (/var/log/sssd/sssd_nss.log). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry, this is a copy-n-paste error. The *ssh* responder log is located at: /var/log/sssd/sssd_ssh.log The path I copied was the *nss* responder log. Sorry again.Ok, so first point, I didn't know I needed a sss responder for ssh (not mentionned anywhere as far as I know). Thanks for this. I added ", ssh" to the "services" line and restarted sssd.
sss_ssh.log stays hopelessly empty even with debug_level 10 and I still have the sshPublicKey is not available in sss_office.log
However sss_ssh_authorizedkeys now doesn't return any error, just a big nothing...
Attached is the ldif of my user (I removed any sensitive information, anyway, the entry has been fetched using anonymous access, so passwords and such has been left aside.
id_provider = ldap auth_provider = ldap chpass_provider = ldap
Hi, I'm afraid we support ssh keys only with IPA backend at the moment.
On Wed, Mar 20, 2013 at 08:12:33AM -0400, Simo Sorce wrote:
On Wed, 2013-03-20 at 10:19 +0100, Pavel Březina wrote:
Hi, I'm afraid we support ssh keys only with IPA backend at the moment.
Should we open a RFE to make it available with other backends too ?
This is already part of https://fedorahosted.org/sssd/ticket/1560 it seems:
""" In the LDAP provider, ldap_user_ssh_public_key has no default value. Make sshPublicKey the default value for it, so that OpenSSH-LPK support is enabled by default. """
On 03/20/2013 01:16 PM, Jakub Hrozek wrote:
On Wed, Mar 20, 2013 at 08:12:33AM -0400, Simo Sorce wrote:
On Wed, 2013-03-20 at 10:19 +0100, Pavel Březina wrote:
Hi, I'm afraid we support ssh keys only with IPA backend at the moment.
Should we open a RFE to make it available with other backends too ?
This is already part of https://fedorahosted.org/sssd/ticket/1560 it seems:
""" In the LDAP provider, ldap_user_ssh_public_key has no default value. Make sshPublicKey the default value for it, so that OpenSSH-LPK support is enabled by default. """
This sounds more like it should work with LDAP provider if you set ldap_user_ssh_public_key to sshPublicKey. But we don't have any support whatsoever. We lack sssm_ldap_hostid_init().
On 20.3.2013 14:02, Pavel Březina wrote:
On 03/20/2013 01:16 PM, Jakub Hrozek wrote:
On Wed, Mar 20, 2013 at 08:12:33AM -0400, Simo Sorce wrote:
On Wed, 2013-03-20 at 10:19 +0100, Pavel Březina wrote:
Hi, I'm afraid we support ssh keys only with IPA backend at the moment.
Should we open a RFE to make it available with other backends too ?
This is already part of https://fedorahosted.org/sssd/ticket/1560 it seems:
""" In the LDAP provider, ldap_user_ssh_public_key has no default value. Make sshPublicKey the default value for it, so that OpenSSH-LPK support is enabled by default. """
This sounds more like it should work with LDAP provider if you set ldap_user_ssh_public_key to sshPublicKey.
Yes, it should.
But we don't have any support whatsoever. We lack sssm_ldap_hostid_init().
This is completely irrelevant for user public keys support.
Honza
2013/3/20 Jan Cholasta jcholast@redhat.com
On 20.3.2013 14:02, Pavel Březina wrote:
On 03/20/2013 01:16 PM, Jakub Hrozek wrote:
On Wed, Mar 20, 2013 at 08:12:33AM -0400, Simo Sorce wrote:
On Wed, 2013-03-20 at 10:19 +0100, Pavel Březina wrote:
Hi, I'm afraid we support ssh keys only with IPA backend at the moment.
Should we open a RFE to make it available with other backends too ?
This is already part of https://fedorahosted.org/sssd/**ticket/1560https://fedorahosted.org/sssd/ticket/1560it seems:
""" In the LDAP provider, ldap_user_ssh_public_key has no default value. Make sshPublicKey the default value for it, so that OpenSSH-LPK support is enabled by default. """
This sounds more like it should work with LDAP provider if you set ldap_user_ssh_public_key to sshPublicKey.
Yes, it should.
But we don't have any support
whatsoever. We lack sssm_ldap_hostid_init().
This is completely irrelevant for user public keys support.
Honza
-- Jan Cholasta
Hello,
Thanks for all the messages. I did add the ldap_user_public_key to sssd.conf, but it doesn't seem to change anything.
In fact, sshPublicKey isn't even requested during the ldap_search_ext/sdap_get_generic_ext_step call.
I tried to find information on IPA backend, but it seems quite unclear what this would be. Attached is an up-to-date sanitized sssd.conf.
If you have any other insight, I'd be glad to test them or provide additional informations.
Mathieu.
On 20.3.2013 15:41, Mathieu Lemoine wrote:
Hello,
Thanks for all the messages. I did add the ldap_user_public_key to sssd.conf, but it doesn't seem to change anything.
In fact, sshPublicKey isn't even requested during the ldap_search_ext/sdap_get_generic_ext_step call.
I tried to find information on IPA backend, but it seems quite unclear what this would be. Attached is an up-to-date sanitized sssd.conf.
If you have any other insight, I'd be glad to test them or provide additional informations.
Mathieu.
The option is named "ldap_user_ssh_public_key", not "ldap_user_public_key".
Honza
My Bad... And there we go, everything seems to be working just fine. Thank you very much for your help!
I'll give it a rest for a couple of days to make sure the cache is working fine for my use case and then I'll document my experience in a blog post. I hope this will be able to help others and prevent further stupid mistakes like mine!
Thanks again, Mathieu.
2013/3/20 Jan Cholasta jcholast@redhat.com
On 20.3.2013 15:41, Mathieu Lemoine wrote:
Hello,
Thanks for all the messages. I did add the ldap_user_public_key to sssd.conf, but it doesn't seem to change anything.
In fact, sshPublicKey isn't even requested during the ldap_search_ext/sdap_get_**generic_ext_step call.
I tried to find information on IPA backend, but it seems quite unclear what this would be. Attached is an up-to-date sanitized sssd.conf.
If you have any other insight, I'd be glad to test them or provide additional informations.
Mathieu.
The option is named "ldap_user_ssh_public_key", not "ldap_user_public_key".
Honza
-- Jan Cholasta
On Wed, Mar 20, 2013 at 12:26:51PM -0400, Mathieu Lemoine wrote:
My Bad... And there we go, everything seems to be working just fine. Thank you very much for your help!
I'll give it a rest for a couple of days to make sure the cache is working fine for my use case and then I'll document my experience in a blog post. I hope this will be able to help others and prevent further stupid mistakes like mine!
Thanks again, Mathieu.
That would be great, thank you. Please let us know when/if you publish that blog post. I think it would be nice to link it from the sssd wiki or turn it into a howto document there.
2013/3/20 Jan Cholasta jcholast@redhat.com
On 20.3.2013 15:41, Mathieu Lemoine wrote:
Hello,
Thanks for all the messages. I did add the ldap_user_public_key to sssd.conf, but it doesn't seem to change anything.
In fact, sshPublicKey isn't even requested during the ldap_search_ext/sdap_get_**generic_ext_step call.
I tried to find information on IPA backend, but it seems quite unclear what this would be. Attached is an up-to-date sanitized sssd.conf.
If you have any other insight, I'd be glad to test them or provide additional informations.
Mathieu.
The option is named "ldap_user_ssh_public_key", not "ldap_user_public_key".
Honza
-- Jan Cholasta
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 03/19/2013 01:52 PM, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages https://launchpad.net/%7Enicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
See the slide deck attached. I suspect the implimatation assumes ipa schema not the one you mention. And the reason is that we have found other schemata limiting.
HTH
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hello,
Me again. As promised, here is the link to the blog post: http://blog.mlemoine.name/2013/04/11/centralizing-server-access.html
Enjoy! (Feedback is welcome and will be appreciated.)
Mathieu.
2013/3/25 Dmitri Pal dpal@redhat.com
On 03/19/2013 01:52 PM, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packageshttps://launchpad.net/%7Enicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
See the slide deck attached. I suspect the implimatation assumes ipa schema not the one you mention. And the reason is that we have found other schemata limiting.
HTH
sssd-users mailing listsssd-users@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs?www.redhat.com/carveoutcosts/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 04/11/2013 02:04 PM, Mathieu Lemoine wrote:
Hello,
Me again. As promised, here is the link to the blog post: http://blog.mlemoine.name/2013/04/11/centralizing-server-access.html
Enjoy! (Feedback is welcome and will be appreciated.)
Thank you for the pointer. Several commends
s/SSSd/SSSD
Please remove enumeration. We ask people not to use enumeration up until it is really needed. So if you "really need it" please say that your case is somewhat odd. The enumeration creates a lot of burden on the server. The enumeration is needed only in the case when the servers you access run unattended for a long period of time with noone *ever* logging into them. If this is the case then enumeration is probably the right thing to do as this is the only way to sync up data and make it available before outage for the case of outage. However in most cases people log into the systems periodically. In this case the data is cached and the enumeration is really not needed. Can you please augment it in the article? It is really important because people start to use enumerate = true and get into delays when they really do not need to use enumeration. Also I am not sure that enumeration really affects the data that is needed for SSH integration. Can someone confirm that please?
"to read about this match, " did you mean "patch"?
Thanks Dmitri
Mathieu.
2013/3/25 Dmitri Pal <dpal@redhat.com mailto:dpal@redhat.com>
On 03/19/2013 01:52 PM, Mathieu Lemoine wrote:Hello, I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages <https://launchpad.net/%7Enicholas-hatch/+archive/auth/+packages>) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great. My issue now lies with the SSH public key. My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute. sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it... If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.See the slide deck attached. I suspect the implimatation assumes ipa schema not the one you mention. And the reason is that we have found other schemata limiting. HTH_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-users-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/> _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thanks Dimitri for the feedback.
I made the modifications you asked for. Including a disclaimer regarding enumerate. I wasn't aware of this issue by the way. So thank you.
From what I can made out of the logs I was given to read, I think SSSD
actually fetch the ssh public key during the enumerate phase along with all the others LDAP fields.
BTW, please refer to the version I linked here and not the one on mentel.com. Because this is the one I'll keep updating on a long term basis. The company webmaster won't like having updates each times I'll find a neat trick to refine the config. And I do hope to include further tips on my blog as I'll keep working with SSSD (For example, I intend to take a look at the kerberos integration some time in the future).
Mathieu.
2013/4/11 Dmitri Pal dpal@redhat.com
On 04/11/2013 02:04 PM, Mathieu Lemoine wrote:
Hello,
Me again. As promised, here is the link to the blog post: http://blog.mlemoine.name/2013/04/11/centralizing-server-access.html
Enjoy! (Feedback is welcome and will be appreciated.)
Thank you for the pointer. Several commends
s/SSSd/SSSD
Please remove enumeration. We ask people not to use enumeration up until it is really needed. So if you "really need it" please say that your case is somewhat odd. The enumeration creates a lot of burden on the server. The enumeration is needed only in the case when the servers you access run unattended for a long period of time with noone *ever* logging into them. If this is the case then enumeration is probably the right thing to do as this is the only way to sync up data and make it available before outage for the case of outage. However in most cases people log into the systems periodically. In this case the data is cached and the enumeration is really not needed. Can you please augment it in the article? It is really important because people start to use enumerate = true and get into delays when they really do not need to use enumeration. Also I am not sure that enumeration really affects the data that is needed for SSH integration. Can someone confirm that please?
"to read about this match, " did you mean "patch"?
Thanks Dmitri
Mathieu.
2013/3/25 Dmitri Pal dpal@redhat.com
On 03/19/2013 01:52 PM, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packageshttps://launchpad.net/%7Enicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
See the slide deck attached. I suspect the implimatation assumes ipa schema not the one you mention. And the reason is that we have found other schemata limiting.
HTH
sssd-users mailing listsssd-users@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs?www.redhat.com/carveoutcosts/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs?www.redhat.com/carveoutcosts/
On 04/11/2013 02:44 PM, Mathieu Lemoine wrote:
Thanks Dimitri for the feedback.
I made the modifications you asked for. Including a disclaimer regarding enumerate. I wasn't aware of this issue by the way. So thank you.
From what I can made out of the logs I was given to read, I think SSSD actually fetch the ssh public key during the enumerate phase along with all the others LDAP fields.
BTW, please refer to the version I linked here and not the one on mentel.com http://mentel.com. Because this is the one I'll keep updating on a long term basis. The company webmaster won't like having updates each times I'll find a neat trick to refine the config. And I do hope to include further tips on my blog as I'll keep working with SSSD (For example, I intend to take a look at the kerberos integration some time in the future).
Yes. Thank you. Looks good.
Couple questions: 1) Are you planning to consider FreeIPA? 2) Is there any chance you can blog about the SSSD test day?
http://fedoraproject.org/wiki/QA/Fedora_19_test_days Currently there are three test days on the list that we will be running. Next week there will be an IPA one. We already started to prepare test cases for it http://fedoraproject.org/wiki/Test_Day:2013-04-18 There will be a similar page created for SSSD. The date is 2013-05-09 and the focus is "SSSD Improve and AD Integration" And then later in early June we will try out the FreeIPA with a native OTP support!
Thanks Dmitri
Mathieu.
2013/4/11 Dmitri Pal <dpal@redhat.com mailto:dpal@redhat.com>
On 04/11/2013 02:04 PM, Mathieu Lemoine wrote:Hello, Me again. As promised, here is the link to the blog post: http://blog.mlemoine.name/2013/04/11/centralizing-server-access.html Enjoy! (Feedback is welcome and will be appreciated.)Thank you for the pointer. Several commends s/SSSd/SSSD Please remove enumeration. We ask people not to use enumeration up until it is really needed. So if you "really need it" please say that your case is somewhat odd. The enumeration creates a lot of burden on the server. The enumeration is needed only in the case when the servers you access run unattended for a long period of time with noone *ever* logging into them. If this is the case then enumeration is probably the right thing to do as this is the only way to sync up data and make it available before outage for the case of outage. However in most cases people log into the systems periodically. In this case the data is cached and the enumeration is really not needed. Can you please augment it in the article? It is really important because people start to use enumerate = true and get into delays when they really do not need to use enumeration. Also I am not sure that enumeration really affects the data that is needed for SSH integration. Can someone confirm that please? "to read about this match, " did you mean "patch"? Thanks DmitriMathieu. 2013/3/25 Dmitri Pal <dpal@redhat.com <mailto:dpal@redhat.com>> On 03/19/2013 01:52 PM, Mathieu Lemoine wrote:Hello, I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packages <https://launchpad.net/%7Enicholas-hatch/+archive/auth/+packages>) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great. My issue now lies with the SSH public key. My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute. sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it... If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.See the slide deck attached. I suspect the implimatation assumes ipa schema not the one you mention. And the reason is that we have found other schemata limiting. HTH_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-users-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/> _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-users-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
I may take a look to FreeIPA in the future, but it's not in my immediate plans.
As you can see, my blog is low traffic and low content. I'm really not sure if it will help to blog about the test days. But I'll make sure to take a look at it and eventually add a note about'em.
Thanks again for the feedback.
Mathieu. On Apr 11, 2013 3:24 PM, "Dmitri Pal" dpal@redhat.com wrote:
On 04/11/2013 02:44 PM, Mathieu Lemoine wrote:
Thanks Dimitri for the feedback.
I made the modifications you asked for. Including a disclaimer regarding enumerate. I wasn't aware of this issue by the way. So thank you.
From what I can made out of the logs I was given to read, I think SSSD actually fetch the ssh public key during the enumerate phase along with all the others LDAP fields.
BTW, please refer to the version I linked here and not the one on mentel.com. Because this is the one I'll keep updating on a long term basis. The company webmaster won't like having updates each times I'll find a neat trick to refine the config. And I do hope to include further tips on my blog as I'll keep working with SSSD (For example, I intend to take a look at the kerberos integration some time in the future).
Yes. Thank you. Looks good.
Couple questions:
- Are you planning to consider FreeIPA?
- Is there any chance you can blog about the SSSD test day?
http://fedoraproject.org/wiki/QA/Fedora_19_test_days Currently there are three test days on the list that we will be running. Next week there will be an IPA one. We already started to prepare test cases for it http://fedoraproject.org/wiki/Test_Day:2013-04-18 There will be a similar page created for SSSD. The date is 2013-05-09 and the focus is "SSSD Improve and AD Integration" And then later in early June we will try out the FreeIPA with a native OTP support!
Thanks Dmitri
Mathieu.
2013/4/11 Dmitri Pal dpal@redhat.com
On 04/11/2013 02:04 PM, Mathieu Lemoine wrote:
Hello,
Me again. As promised, here is the link to the blog post: http://blog.mlemoine.name/2013/04/11/centralizing-server-access.html
Enjoy! (Feedback is welcome and will be appreciated.)
Thank you for the pointer. Several commends
s/SSSd/SSSD
Please remove enumeration. We ask people not to use enumeration up until it is really needed. So if you "really need it" please say that your case is somewhat odd. The enumeration creates a lot of burden on the server. The enumeration is needed only in the case when the servers you access run unattended for a long period of time with noone *ever* logging into them. If this is the case then enumeration is probably the right thing to do as this is the only way to sync up data and make it available before outage for the case of outage. However in most cases people log into the systems periodically. In this case the data is cached and the enumeration is really not needed. Can you please augment it in the article? It is really important because people start to use enumerate = true and get into delays when they really do not need to use enumeration. Also I am not sure that enumeration really affects the data that is needed for SSH integration. Can someone confirm that please?
"to read about this match, " did you mean "patch"?
Thanks Dmitri
Mathieu.
2013/3/25 Dmitri Pal dpal@redhat.com
On 03/19/2013 01:52 PM, Mathieu Lemoine wrote:
Hello,
I have sssd 1.9.4 (from https://launchpad.net/~nicholas-hatch/+archive/auth/+packageshttps://launchpad.net/%7Enicholas-hatch/+archive/auth/+packages) configured on an OpenLDAP server. getent passwd, getent group, authentication and cache is working great.
My issue now lies with the SSH public key.
My user has the ldapPublicKey objectClass, and the key is in the sshPublicKey attribute.
sss_ssh_authorizedkeys is still returning "Error looking up public keys". An inquiry on the #sssd chan directed me to this mailing-list and more precisely to jcholast, I tried to check out the commits, but nothing seems to get out of it...
If any of you had informations regarding that, it'd be greatly appreciated., Mathieu.
See the slide deck attached. I suspect the implimatation assumes ipa schema not the one you mention. And the reason is that we have found other schemata limiting.
HTH
sssd-users mailing listsssd-users@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs?www.redhat.com/carveoutcosts/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs?www.redhat.com/carveoutcosts/
-- Thank you, Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Looking to carve out IT costs?www.redhat.com/carveoutcosts/
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Jan Cholasta -
Mathieu Lemoine -
Mathieu Lemoine -
Pavel Březina -
Simo Sorce -
Stephen Gallagher