You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running sssd version 1.15.2 or 1.15.3 on CentOS 7.4.1708.
I have a working sssd setup which enables me to sign in using SSH public keys stored in Active Directory.
User are able to log in only once during cache lifetime (by default 90 minutes), otherwise they are denied access. See the merged log of a failed (re)login at https://pastebin.com/Jqc52MWH. For logs with debug_level = 9 see https://pastebin.com/0uQ8MCuS
It's the only way I found to enable login to ssh with username@server.
Disabled default_domain_suffix, deleted cache and tried again:
2nd try failed again: https://pastebin.com/32nhfupp
I can see that user was found few times:
(Wed Oct 4 11:26:24 2017) [sssd[ssh]] [cache_req_search_send] (0x0400): CR #9: Returning [myadmin@example.com] from cache
(Wed Oct 4 11:26:24 2017) [sssd[ssh]] [cache_req_search_ncache_filter] (0x0400): CR #9: This request type does not support filtering result by negative cache
(Wed Oct 4 11:26:24 2017) [sssd[ssh]] [cache_req_create_and_add_result] (0x0400): CR #9: Found 1 entries in domain EXAMPLE.COM
(Wed Oct 4 11:26:24 2017) [sssd[ssh]] [cache_req_done] (0x0400): CR #9: Finished: Success
Could you provide output of following command? ldb_search -H /var/lib/sss/db/cache_$domain.ldb '(objectClass=user)'
Are you sure that use with DN CN=myadmin,OU=Priviledged,OU=User,OU=EXAMPLE,DC=EXAMPLE,DC=COM has attribute sshPublicKey in AD? because IIRC such attribute is not standard in AD. But you might add custom LDIF schema to AD.
Yes I'm sure. I'm able to log in if I clear the cache.
$ date ; ssh -l myadmin@EXAMPLE.COM 10.95.35.126 date; date
Wed Oct 4 13:54:37 CEST 2017
Wed Oct 4 11:54:40 UTC 2017
Wed Oct 4 13:54:41 CEST 2017
(Wed Oct 4 11:54:39 2017) [sssd[be[EXAMPLE.COM]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey [c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUtQaTdqK3N6bkRLL3ZabFhPRUFkcjB5R2w0aFNKUFRTcTdtTDBHLzRmMFEgam9uYXRoYW52b2d0QEpvbmF0aGFucy1NQlAuZnJpdHouYm94] to attributes of [myadmin@example.com].
I assume that https://pagure.io/SSSD/sssd/issue/3534#comment-470311 did not refresh anything from AD because entry in cache was still valid. It is impossible to say without domain log files.
And it should be enough to invalidate entry with sss_cache -u myadmin
Anyway it seems that there is bug with ssh responder and default_domain_suffix in sssd-1.15.x
Sure but IIUC it works without default_domain_suffix + invalidating cache entries (sssd_cache -u user / sss_cache -U). So the only bug is with default_domain_suffix (initial log files)
User are able to log in only once during cache lifetime (by default 90 minutes), otherwise they are denied access. See the merged log of a failed (re)login at https://pastebin.com/Jqc52MWH. For logs with debug_level = 9 see https://pastebin.com/0uQ8MCuS
The problem is the same with and without default_domain_suffix:
I can log in once for a user and then have to wait for a cache refresh due to timeout or invalidation.
According to some of the pasted logs the user is looked up via the Global Catalog from time to time. Do you replicate the sshPublicKey attribute to the Global Catalog? If not setting 'ad_enable_gc = false' in the [domain/...] section of sssd.conf might help, please see man sssd-ad for details.
vorgangsnummer added a new comment to an issue you are following: The attribute was not replicated to the global catalog. Enabling replication or setting `ad_enable_gc = false` enables multiple logins.
I'm glad workaround works for you now. And thank you for bug report
btw I'm not even able to reproduce the issue with the double qualification of the username and looking up user's public keys works fine for me even with default_domain_suffix set to the only domain I have in the config file. Even the debug message has the name qualified only once:
(Thu Oct 5 14:41:42 2017) [sssd[ssh]] [cache_req_search_send] (0x0400): CR #3: Looking up puser@win.trust.test
btw I'm not even able to reproduce the issue with the double qualificatio=
n of the username and looking up user's public keys works fine for me even =
with default_domain_suffix set to the only domain I have in the config file=
. Even the debug message has the name qualified only once:
That=E2=80=99s what I tried to bring across. default_domain_suffix set or=
not does not change the behaviour.
(Thu Oct 5 14:41:42 2017) [sssd[ssh]] [cache_req_search_send] (0x0400): =
--=20 https://goo.gl/cGQj8c
This message and the information contained herein is proprietary and=20
confidential and subject to the AllCloud policy statement, you may review=
=20
it here https://goo.gl/QejddU.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3534
Running sssd version 1.15.2 or 1.15.3 on CentOS 7.4.1708.
I have a working sssd setup which enables me to sign in using SSH public keys stored in Active Directory.
User are able to log in only once during cache lifetime (by default 90 minutes), otherwise they are denied access. See the merged log of a failed (re)login at https://pastebin.com/Jqc52MWH. For logs with debug_level = 9 see https://pastebin.com/0uQ8MCuS
/etc/sssd/sssd.conf
Comments
Comment from vorgangsnummer at 2017-10-04 13:11:39
Same config works on 1.13
Comment from lslebodn at 2017-10-04 13:15:06
Do you really need to use
default_domain_suffix = EXAMPLE.COM
?Because it might explain following line and reason why it is ssh key is not found.
Comment from vorgangsnummer at 2017-10-04 13:33:49
It's the only way I found to enable login to ssh with
username@server
.Disabled
default_domain_suffix
, deleted cache and tried again:2nd try failed again:
https://pastebin.com/32nhfupp
Comment from lslebodn at 2017-10-04 13:40:05
I can see that user was found few times:
Could you provide output of following command?
ldb_search -H /var/lib/sss/db/cache_$domain.ldb '(objectClass=user)'
I am interested whether ssh key is cached or no.
Comment from vorgangsnummer at 2017-10-04 13:46:39
ldbsearch -H /var/lib/sss/db/cache_EXAMPLE.COM.ldb '(objectClass=user)'
I installed ldb-tools and used ldbsearch in case that matters.
Comment from lslebodn at 2017-10-04 13:53:24
OK ssh key is not cached.
Are you sure that use with DN CN=myadmin,OU=Priviledged,OU=User,OU=EXAMPLE,DC=EXAMPLE,DC=COM has attribute
sshPublicKey
in AD? because IIRC such attribute is not standard in AD. But you might add custom LDIF schema to AD.If yes then it would be good to see also related domain log files and not only log files from ssh https://pagure.io/SSSD/sssd/issue/3534#comment-470311
Comment from vorgangsnummer at 2017-10-04 13:59:09
Yes I'm sure. I'm able to log in if I clear the cache.
See https://pastebin.com/RV8iFwr2 for a log
Comment from lslebodn at 2017-10-04 14:05:42
I can see that key was downloaded for second time
I assume that https://pagure.io/SSSD/sssd/issue/3534#comment-470311 did not refresh anything from AD because entry in cache was still valid. It is impossible to say without domain log files.
And it should be enough to invalidate entry with
sss_cache -u myadmin
Anyway it seems that there is bug with ssh responder and
default_domain_suffix
in sssd-1.15.xComment from vorgangsnummer at 2017-10-04 14:13:34
There seems to be no refresh at all. I only see dns traffic in tcpdump when connecting.
Invalidating the cache for the user helps, yes. Also setting
entry_cache_user_timeout = 5
enables a login every 5 seconds.Comment from vorgangsnummer at 2017-10-04 14:45:23
All posted logs since https://pagure.io/SSSD/sssd/issue/3534#comment-470294 where without default_domain_suffix!
Comment from lslebodn at 2017-10-04 14:49:13
Sure but IIUC it works without default_domain_suffix + invalidating cache entries (sssd_cache -u user / sss_cache -U). So the only bug is with
default_domain_suffix
(initial log files)Comment from vorgangsnummer at 2017-10-04 14:55:30
The problem is the same with and without
default_domain_suffix
:I can log in once for a user and then have to wait for a cache refresh due to timeout or invalidation.
Comment from sbose at 2017-10-04 15:20:55
According to some of the pasted logs the user is looked up via the Global Catalog from time to time. Do you replicate the sshPublicKey attribute to the Global Catalog? If not setting 'ad_enable_gc = false' in the [domain/...] section of sssd.conf might help, please see man sssd-ad for details.
Comment from vorgangsnummer at 2017-10-04 15:28:22
The attribute was not replicated to the global catalog. Enabling replication or setting
ad_enable_gc = false
enables multiple logins.Comment from lslebodn at 2017-10-04 15:31:29
On (04/10/17 13:28), Jonathan Vogt wrote:
I'm glad workaround works for you now. And thank you for bug report
LS
Comment from jhrozek at 2017-10-05 16:38:41
The global catalog entry should be solved in a systematic way with https://pagure.io/SSSD/sssd/issue/3538
Comment from jhrozek at 2017-10-05 16:44:04
btw I'm not even able to reproduce the issue with the double qualification of the username and looking up user's public keys works fine for me even with default_domain_suffix set to the only domain I have in the config file. Even the debug message has the name qualified only once:
Therefore I suggest closing this ticket.
Comment from vorgangsnummer at 2017-10-05 16:49:18
CR #3: Looking up puser@win.trust.test
https://pagure.io/SSSD/sssd/issue/3538 <https://pagure.io/SSSD/sssd/issue/3=
538> describes the actually issue way better I guess, so fell free to clos=
e.
--=20
https://goo.gl/cGQj8c
This message and the information contained herein is proprietary and=20
confidential and subject to the AllCloud policy statement, you may review=
=20
it here https://goo.gl/QejddU.
Comment from jhrozek at 2017-10-05 16:54:38
OK, closing.
Comment from jhrozek at 2017-10-05 16:54:51
Metadata Update from @jhrozek:
The text was updated successfully, but these errors were encountered: