Hello Daniel,
Just to clarify the issue:
user '[email protected]' is a member of IDM POSIX group
'cri-cri_server_administrators_ipa' which is linked to the external
group used for the AD trust.
The following HBAC rule is not working to allow SSH access
[root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show
'cri-cri_server_administrators_allow_all'
Rule name: cri-cri_server_administrators_allow_all
Host category: all
Service category: all
Description: Allow anyone in
[email protected]<mailto:[email protected]>
to login to any machine
Enabled: TRUE
User Groups: cri-cri_server_administrators_ipa
==================================================
During the HBAC processing, sssd checks which groups are associated with
the HBAC rule and adds those groups(just the
'cri-cri_server_administrators_ipa' group in this case) to the
memberUser attribute of the HBAC rule sysdb entry.
(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[hbac_attrs_to_rule] (0x1000): Processing rule
[cri-cri_server_administrators_allow_all]
(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_search_groups] (0x2000): Search groups with filter:
(&(objectclass=group)(originalDN=cn=cri-cri_server_administrators_ipa,cn=groups,cn=accounts,dc=ipa,dc=cri,dc=uchicago,dc=edu))
(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[hbac_user_attrs_to_rule] (0x2000): Added POSIX group
[cri-cri_server_administrators_ipa] to rule
[cri-cri_server_administrators_allow_all]
The hbac evaluation reads the originalMemberof attribute of
'[email protected]' to assess the groups which HBAC
should match with
(Wed Jul 13 12:07:13 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[hbac_eval_user_element] (0x1000): [30] groups for
[[email protected]]
With debug logging enabled we should see a message such as the following
when the group is found, but we don't see that in your log output:
[hbac_eval_user_element] Added group
[cri-cri_server_administrators_ipa] for user
[[email protected]]
We need to understand why this group is being removed from the sysdb, as
you said the group does not return in id command output after the SSH
attempt.
It would be great to get full sssd debug logs and a dump of the sssd
sysdb cache after the first 'id' command is run, and then after the SSH
attempt is made when the group no longer shows. Note the ldbsearch
command is included in the 'ldb-tools' rpm
For example:
ldbsearch -H /var/lib/sss/db/cache_<domain>.ldb >
ldbsearch-first-id-command.ldb
ldbsearch -H /var/lib/sss/db/cache_<domain>.ldb >
ldbsearch-after-ssh-attempt.ldb
Kind regards,
Justin Stephenson
On 07/13/2016 03:14 PM, Sullivan, Daniel [AAA] wrote:
Jakub, Justin,
Thank you both very much for taking the time to continue helping me resolve
this issue. I apologize for not replying right away; I’ve been dealing with a
production issue for most of the morning.
An invocation of ‘id
[email protected]<mailto:[email protected]>’ on the IPA DC
shows me as a member of the POSIX IPA group
([email protected]<mailto:[email protected]>)
as well as the AD domain group in the trusted domain
([email protected]<mailto:[email protected]>).
This remains consistent across any number of successful sshd logins into the DC using my
[email protected]<mailto:[email protected]>.edu account, including
after clearing the cache on the DC.
On the client, I am seeing some unusual behavior. If I run the commands 'sss_cache -E;
service sssd stop ; rm -rf /var/log/sssd/* ; service sssd start’ , then run ‘id
[email protected]<mailto:[email protected]>’, I see
the POSIX IPA group as well as the AD domain group as described above (what I presumably
want and expect). However (and this is the unusual part), if I attempt to login via SSH
(it will fail with HBAC validation), and then run the ‘id
[email protected]<mailto:[email protected]>’
command again , the POSIX IPA group disappears from the list of groups output by the id
command. From what I can tell, this group will not reappear in the group list on the
client until the client cache is cleared. Presumably this behavior is related to the HBAC
authentication errors I am experiencing. I have cleared the cache on both the DC and the
client using ssh_cache -E and this behavior is still exhibited. With respect to output
from testing:
1) The sssd domain log from from the client of the initial id invocation (both groups
appear) after clearing the cache (on the client) can be found here (this output
contains both groups):
https://gist.github.com/dsulli99/7117f8d567cc7cdf727d474b0aeab8da<http://pastebin.com/BpAHfYEP>
2) The sssd domain log from the client for the failed sshd login (similar to the
output I provided yesterday, however re-captured) can be found here (after this
operation the IPA group disappears from the list of groups from the id command):
https://gist.github.com/dsulli99/668a8799709ff0cd311b321206591124<http://pastebin.com/tnuAbvmV>
3) The DC log (after the client cache is cleared) of my running the id
invocation (from the client) can be found here (this is the DC side of 1) from
above. https://gist.github.com/dsulli99/a2a5e80b6a8b143afa20024aa40a7b39
4) The DC log of the the failed sshd login into the client (this is the DC side
of 2) from above is
https://gist.github.com/dsulli99/4e3ba53c942ad78d7487ae51da92007e
I really appreciate your help with looking at this issue. As I said I have
another machine built from the same image that this is working fine on. I am
going to keep plugging away at this, I will let you know if I come up with
anything.
Dan
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************
--
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
