Hi everybody.
I have just upgraded my cluster from FreeIPA 4.4.0-14 to 4.6.4-10. All is good, logging via IPA credentials, HBAC and sudo rules are working. I have only a issue logging via SSH with AD credentials. Before the upgrade all was working well.
I think that the trust is ok, because *kinit*, *ipa hbactest* and *ipa trustdomain-find* (on both ipa servers) are working well:
*[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM http://MYDOMAIN.COM Domain name: mydomain.com http://mydomain.com Domain NetBIOS name: MYDOMAIN Domain Security Identifier: S-1-5-21-3367759252-2451474351-126822339 Domain enabled: True----------------------------Number of entries returned 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com --host=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comService: sshd--------------------Access granted: True-------------------- Matched rules: allow_ad_ipa_admins Not matched rules: allow_ad_ipa_apps Not matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit morgan.marodin@mydomain.com morgan.marodin@mydomain.comPassword for morgan.marodin@mydomain.com morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]# klistTicket cache: KEYRING:persistent:0:0Default principal: morgan.marodin@MYDOMAIN.COM morgan.marodin@MYDOMAIN.COMValid starting Expires Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM renew until 02/20/2019 17:55:18*
This is the error log:
*[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account): Access denied for user morgan.marodin@mydomain.com morgan.marodin@mydomain.com: 6 (Permission denied)Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: User account has expired for morgan.marodin@mydomain.com morgan.marodin@mydomain.com from 192.168.100.252Feb 19 18:03:21 mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted request 104*
It seems a problem with pam and sssd. Do you have any suggestions?
Thanks, bye. Morgan
On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via FreeIPA-users wrote:
Hi everybody.
I have just upgraded my cluster from FreeIPA 4.4.0-14 to 4.6.4-10. All is good, logging via IPA credentials, HBAC and sudo rules are working. I have only a issue logging via SSH with AD credentials. Before the upgrade all was working well.
I think that the trust is ok, because *kinit*, *ipa hbactest* and *ipa trustdomain-find* (on both ipa servers) are working well:
*[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM http://MYDOMAIN.COM Domain name: mydomain.com http://mydomain.com Domain NetBIOS name: MYDOMAIN Domain Security Identifier: S-1-5-21-3367759252-2451474351-126822339 Domain enabled: True----------------------------Number of entries returned 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com --host=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comService: sshd--------------------Access granted: True-------------------- Matched rules: allow_ad_ipa_admins Not matched rules: allow_ad_ipa_apps Not matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit morgan.marodin@mydomain.com morgan.marodin@mydomain.comPassword for morgan.marodin@mydomain.com morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]# klistTicket cache: KEYRING:persistent:0:0Default principal: morgan.marodin@MYDOMAIN.COM morgan.marodin@MYDOMAIN.COMValid starting Expires Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM renew until 02/20/2019 17:55:18*
This is the error log:
*[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account): Access denied for user morgan.marodin@mydomain.com morgan.marodin@mydomain.com: 6 (Permission denied)
This is returned by SSSD, please add debug_level=9 to the [domain/...] section of sssd.conf, restart, SSSD and try to login again. In the domain log you should find the evaluation of the HBAC rules which might explain why access was denied.
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: User account has expired for morgan.marodin@mydomain.com morgan.marodin@mydomain.com from 192.168.100.252
I'm not sure where this message comes from. I had a short look at the ssh and PAM source code, but so far didn't find a matching messages.
bye, Sumit
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted request 104*
It seems a problem with pam and sssd. Do you have any suggestions?
Thanks, bye. Morgan
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
I did some tests, because some times SSH logins worked ... and sometimes not.
It seems that the problem is not client side: - if I stop the 1st IPA server I'm able to login via SSH via AD credentials - if I stop the 2nd one (after started the other one, naturally) the issue appears again
With only the issued server started the I'm able to do a *kinit* correctly. What could I check server side?
Please let me know, thanks. Morgan
Il giorno mar 19 feb 2019 alle ore 19:57 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via FreeIPA-users wrote:
Hi everybody.
I have just upgraded my cluster from FreeIPA 4.4.0-14 to 4.6.4-10. All is good, logging via IPA credentials, HBAC and sudo rules are
working.
I have only a issue logging via SSH with AD credentials. Before the
upgrade
all was working well.
I think that the trust is ok, because *kinit*, *ipa hbactest* and *ipa trustdomain-find* (on both ipa servers) are working well:
*[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM http://MYDOMAIN.COM Domain name: mydomain.com http://mydomain.com Domain NetBIOS name: MYDOMAIN Domain Security Identifier: S-1-5-21-3367759252-2451474351-126822339 Domain enabled: True----------------------------Number of entries returned 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com --host=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comService: sshd--------------------Access granted: True-------------------- Matched rules: allow_ad_ipa_admins Not matched rules: allow_ad_ipa_apps Not matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit morgan.marodin@mydomain.com morgan.marodin@mydomain.comPassword for morgan.marodin@mydomain.com morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]# klistTicket cache: KEYRING:persistent:0:0Default principal: morgan.marodin@MYDOMAIN.COM morgan.marodin@MYDOMAIN.COMValid starting Expires Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM
renew
until 02/20/2019 17:55:18*
This is the error log:
*[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account): Access denied for user morgan.marodin@mydomain.com morgan.marodin@mydomain.com: 6 (Permission denied)
This is returned by SSSD, please add debug_level=9 to the [domain/...] section of sssd.conf, restart, SSSD and try to login again. In the domain log you should find the evaluation of the HBAC rules which might explain why access was denied.
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: User account has expired for morgan.marodin@mydomain.com morgan.marodin@mydomain.com from 192.168.100.252
I'm not sure where this message comes from. I had a short look at the ssh and PAM source code, but so far didn't find a matching messages.
bye, Sumit
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted request 104*
It seems a problem with pam and sssd. Do you have any suggestions?
Thanks, bye. Morgan
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On Thu, Feb 21, 2019 at 03:47:15PM +0100, Morgan Marodin via FreeIPA-users wrote:
I did some tests, because some times SSH logins worked ... and sometimes not.
It seems that the problem is not client side:
- if I stop the 1st IPA server I'm able to login via SSH via AD credentials
- if I stop the 2nd one (after started the other one, naturally) the issue
appears again
With only the issued server started the I'm able to do a *kinit* correctly. What could I check server side?
I think it would be better to check the SSSD logs on the client side. Please add debug_level=9 to the [pam] and [domain/...] sections of sssd.conf, restart SSSD and retry the login with only the 1st server running to reproduce the issue.
According to the log snippet you send earlier, it is expected that kinit works fine because the authentication step 'pam_sss(sshd:auth)' was successful. This is the step which does a similar operation as kinit. The failure was in the next step 'pam_sss(sshd:access)' which is access control.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 19 feb 2019 alle ore 19:57 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via FreeIPA-users wrote:
Hi everybody.
I have just upgraded my cluster from FreeIPA 4.4.0-14 to 4.6.4-10. All is good, logging via IPA credentials, HBAC and sudo rules are
working.
I have only a issue logging via SSH with AD credentials. Before the
upgrade
all was working well.
I think that the trust is ok, because *kinit*, *ipa hbactest* and *ipa trustdomain-find* (on both ipa servers) are working well:
*[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM http://MYDOMAIN.COM Domain name: mydomain.com http://mydomain.com Domain NetBIOS name: MYDOMAIN Domain Security Identifier: S-1-5-21-3367759252-2451474351-126822339 Domain enabled: True----------------------------Number of entries returned 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com --host=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comService: sshd--------------------Access granted: True-------------------- Matched rules: allow_ad_ipa_admins Not matched rules: allow_ad_ipa_apps Not matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit morgan.marodin@mydomain.com morgan.marodin@mydomain.comPassword for morgan.marodin@mydomain.com morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]# klistTicket cache: KEYRING:persistent:0:0Default principal: morgan.marodin@MYDOMAIN.COM morgan.marodin@MYDOMAIN.COMValid starting Expires Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM
renew
until 02/20/2019 17:55:18*
This is the error log:
*[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account): Access denied for user morgan.marodin@mydomain.com morgan.marodin@mydomain.com: 6 (Permission denied)
This is returned by SSSD, please add debug_level=9 to the [domain/...] section of sssd.conf, restart, SSSD and try to login again. In the domain log you should find the evaluation of the HBAC rules which might explain why access was denied.
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: User account has expired for morgan.marodin@mydomain.com morgan.marodin@mydomain.com from 192.168.100.252
I'm not sure where this message comes from. I had a short look at the ssh and PAM source code, but so far didn't find a matching messages.
bye, Sumit
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted request 104*
It seems a problem with pam and sssd. Do you have any suggestions?
Thanks, bye. Morgan
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
No, it's not true. It's random ... it not depends (maybe) from the server. You can find attached the debug logs from the test client, thanks
Il giorno gio 21 feb 2019 alle ore 16:01 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Thu, Feb 21, 2019 at 03:47:15PM +0100, Morgan Marodin via FreeIPA-users wrote:
I did some tests, because some times SSH logins worked ... and sometimes not.
It seems that the problem is not client side:
- if I stop the 1st IPA server I'm able to login via SSH via AD
credentials
- if I stop the 2nd one (after started the other one, naturally) the
issue
appears again
With only the issued server started the I'm able to do a *kinit*
correctly.
What could I check server side?
I think it would be better to check the SSSD logs on the client side. Please add debug_level=9 to the [pam] and [domain/...] sections of sssd.conf, restart SSSD and retry the login with only the 1st server running to reproduce the issue.
According to the log snippet you send earlier, it is expected that kinit works fine because the authentication step 'pam_sss(sshd:auth)' was successful. This is the step which does a similar operation as kinit. The failure was in the next step 'pam_sss(sshd:access)' which is access control.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 19 feb 2019 alle ore 19:57 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via
FreeIPA-users
wrote:
Hi everybody.
I have just upgraded my cluster from FreeIPA 4.4.0-14 to 4.6.4-10. All is good, logging via IPA credentials, HBAC and sudo rules are
working.
I have only a issue logging via SSH with AD credentials. Before the
upgrade
all was working well.
I think that the trust is ok, because *kinit*, *ipa hbactest* and
*ipa
trustdomain-find* (on both ipa servers) are working well:
*[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM http://MYDOMAIN.COM Domain name: mydomain.com <
Domain NetBIOS name: MYDOMAIN Domain Security Identifier: S-1-5-21-3367759252-2451474351-126822339 Domain enabled: True----------------------------Number of entries returned 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com --host=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comService: sshd--------------------Access granted: True--------------------
Matched
rules: allow_ad_ipa_admins Not matched rules: allow_ad_ipa_apps Not matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit morgan.marodin@mydomain.com morgan.marodin@mydomain.comPassword
for
morgan.marodin@mydomain.com morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]# klistTicket
cache:
KEYRING:persistent:0:0Default principal: morgan.marodin@MYDOMAIN.COM morgan.marodin@MYDOMAIN.COMValid starting Expires Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM
renew
until 02/20/2019 17:55:18*
This is the error log:
*[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication
success;
logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account): Access
denied
for user morgan.marodin@mydomain.com morgan.marodin@mydomain.com:
6
(Permission denied)
This is returned by SSSD, please add debug_level=9 to the [domain/...] section of sssd.conf, restart, SSSD and try to login again. In the domain log you should find the evaluation of the HBAC rules which might explain why access was denied.
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: User account has expired for morgan.marodin@mydomain.com morgan.marodin@mydomain.com from 192.168.100.252
I'm not sure where this message comes from. I had a short look at the ssh and PAM source code, but so far didn't find a matching messages.
bye, Sumit
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted request
104*
It seems a problem with pam and sssd. Do you have any suggestions?
Thanks, bye. Morgan
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On Mon, Feb 25, 2019 at 09:02:30AM +0100, Morgan Marodin wrote:
No, it's not true. It's random ... it not depends (maybe) from the server. You can find attached the debug logs from the test client, thanks
Hi,
at the end of the logs you can see the evaluation of the HBAC rules:
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_evaluate] (0x0100): [< hbac_evaluate() (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): REQUEST: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service [sshd] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user [morgan.marodin] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost [mlv-testipa01.ipa.mydomain.com] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost [192.168.100.252] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): request time 2019-02-21 16:04:23 (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ipa_it_mysite] [ENABLED]: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): services: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): users: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_names (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_groups: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): [ipa_it_mysite] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): targethosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): srchosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_evaluate] (0x0100): The rule [allow_ipa_it_mysite] did not match.
......
The allow_ipa_it_mysite and all other rules do not match because
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none)
Earlier in the logs, when the group memberships of the user are looked up:
(Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): Received [7] groups in group list from IPA Server (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [morgan.marodin@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [local proxy exclusion@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite signature@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite users@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [ipa admins@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite it@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [domain users@mydomain.com].
there are only groups from the AD domain and the IPA group memberships are missing.
I would expect that 'id morgan.marodin@mydomain.com' only returns the groups listed above both on the client and on the server. Since the client gets the group-memberships from the server the next step would be to check the server logs.
For this please call 'sss_cache -E' on the server to invalidate the cache on the server and then 'id morgan.marodin@mydomain.com' on the server and send the logs covering the time of the id request. Please do not forget to set debug_level=9 in the [nss] and [domain/...] sections on the IPA server.
bye, Sumit
Il giorno gio 21 feb 2019 alle ore 16:01 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Thu, Feb 21, 2019 at 03:47:15PM +0100, Morgan Marodin via FreeIPA-users wrote:
I did some tests, because some times SSH logins worked ... and sometimes not.
It seems that the problem is not client side:
- if I stop the 1st IPA server I'm able to login via SSH via AD
credentials
- if I stop the 2nd one (after started the other one, naturally) the
issue
appears again
With only the issued server started the I'm able to do a *kinit*
correctly.
What could I check server side?
I think it would be better to check the SSSD logs on the client side. Please add debug_level=9 to the [pam] and [domain/...] sections of sssd.conf, restart SSSD and retry the login with only the 1st server running to reproduce the issue.
According to the log snippet you send earlier, it is expected that kinit works fine because the authentication step 'pam_sss(sshd:auth)' was successful. This is the step which does a similar operation as kinit. The failure was in the next step 'pam_sss(sshd:access)' which is access control.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 19 feb 2019 alle ore 19:57 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via
FreeIPA-users
wrote:
Hi everybody.
I have just upgraded my cluster from FreeIPA 4.4.0-14 to 4.6.4-10. All is good, logging via IPA credentials, HBAC and sudo rules are
working.
I have only a issue logging via SSH with AD credentials. Before the
upgrade
all was working well.
I think that the trust is ok, because *kinit*, *ipa hbactest* and
*ipa
trustdomain-find* (on both ipa servers) are working well:
*[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM http://MYDOMAIN.COM Domain name: mydomain.com <
Domain NetBIOS name: MYDOMAIN Domain Security Identifier: S-1-5-21-3367759252-2451474351-126822339 Domain enabled: True----------------------------Number of entries returned 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com --host=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comService: sshd--------------------Access granted: True--------------------
Matched
rules: allow_ad_ipa_admins Not matched rules: allow_ad_ipa_apps Not matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit morgan.marodin@mydomain.com morgan.marodin@mydomain.comPassword
for
morgan.marodin@mydomain.com morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]# klistTicket
cache:
KEYRING:persistent:0:0Default principal: morgan.marodin@MYDOMAIN.COM morgan.marodin@MYDOMAIN.COMValid starting Expires Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM
renew
until 02/20/2019 17:55:18*
This is the error log:
*[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication
success;
logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account): Access
denied
for user morgan.marodin@mydomain.com morgan.marodin@mydomain.com:
6
(Permission denied)
This is returned by SSSD, please add debug_level=9 to the [domain/...] section of sssd.conf, restart, SSSD and try to login again. In the domain log you should find the evaluation of the HBAC rules which might explain why access was denied.
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: User account has expired for morgan.marodin@mydomain.com morgan.marodin@mydomain.com from 192.168.100.252
I'm not sure where this message comes from. I had a short look at the ssh and PAM source code, but so far didn't find a matching messages.
bye, Sumit
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted request
104*
It seems a problem with pam and sssd. Do you have any suggestions?
Thanks, bye. Morgan
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA group *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in Active Directory. I tested the *id morgan.marodin@mydomain.com morgan.marodin@mydomain.com* command both in the client and the server, they differ only for the last part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
But the same client, as said last time, sometimes works correctly, please see these logs captured doing a SSH connection with the AD credential, after cleaning manually the sssd cache of the client:
*[root@mlv-testipa01 ~]# systemctl stop sssd ; rm -rf /var/lib/sss/db/* ; systemctl start sssd[root@mlv-testipa01 ~]# tail -f /var/log/sssd/*log | grep -i allow(Mon Feb 25 15:35:41 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=ipa,dc=mydomain,dc=com][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(memberHost=fqdn=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.com,cn=computers,cn=accounts,dc=ipa,dc=mydomain,dc=com)))](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(memberHost=fqdn=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.com,cn=computers,cn=accounts,dc=ipa,dc=mydomain,dc=com)))][cn=hbac,dc=ipa,dc=mydomain,dc=com].(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x2000): Added non-POSIX group [ipa_it_mysite] to rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x2000): Added POSIX group [ad_ipa_admins@ipa.mydomain.com ad_ipa_admins@ipa.mydomain.com] to rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x2000): Added service [sshd] to rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ipa_it_mysite] [ENABLED]:(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_evaluate] (0x0100): The rule [allow_ipa_it_mysite] did not match.(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ad_ipa_admins] [ENABLED]:(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_evaluate] (0x0100): ALLOWED by rule [allow_ad_ipa_admins].(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap]*
So it's a strange behaviour because sometimes it worked and sometimes not. Which logs shoul be useful now?
Please let me know, thanks
Il giorno lun 25 feb 2019 alle ore 09:45 Sumit Bose sbose@redhat.com ha scritto:
On Mon, Feb 25, 2019 at 09:02:30AM +0100, Morgan Marodin wrote:
No, it's not true. It's random ... it not depends (maybe) from the
server.
You can find attached the debug logs from the test client, thanks
Hi,
at the end of the logs you can see the evaluation of the HBAC rules:
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_evaluate] (0x0100): [< hbac_evaluate() (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): REQUEST: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service [sshd] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user [morgan.marodin] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost [ mlv-testipa01.ipa.mydomain.com] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost [192.168.100.252] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): request time 2019-02-21 16:04:23 (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ipa_it_mysite] [ENABLED]: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): services: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): users: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_names (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_groups: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): [ipa_it_mysite] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): targethosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): srchosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_evaluate] (0x0100): The rule [allow_ipa_it_mysite] did not match.
......
The allow_ipa_it_mysite and all other rules do not match because
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none)
Earlier in the logs, when the group memberships of the user are looked up:
(Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): Received [7] groups in group list from IPA Server (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [morgan.marodin@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [local proxy exclusion@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite signature@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite users@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [ipa admins@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite it@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [domain users@mydomain.com].
there are only groups from the AD domain and the IPA group memberships are missing.
I would expect that 'id morgan.marodin@mydomain.com' only returns the groups listed above both on the client and on the server. Since the client gets the group-memberships from the server the next step would be to check the server logs.
For this please call 'sss_cache -E' on the server to invalidate the cache on the server and then 'id morgan.marodin@mydomain.com' on the server and send the logs covering the time of the id request. Please do not forget to set debug_level=9 in the [nss] and [domain/...] sections on the IPA server.
bye, Sumit
Il giorno gio 21 feb 2019 alle ore 16:01 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Thu, Feb 21, 2019 at 03:47:15PM +0100, Morgan Marodin via
FreeIPA-users
wrote:
I did some tests, because some times SSH logins worked ... and
sometimes
not.
It seems that the problem is not client side:
- if I stop the 1st IPA server I'm able to login via SSH via AD
credentials
- if I stop the 2nd one (after started the other one, naturally) the
issue
appears again
With only the issued server started the I'm able to do a *kinit*
correctly.
What could I check server side?
I think it would be better to check the SSSD logs on the client side. Please add debug_level=9 to the [pam] and [domain/...] sections of sssd.conf, restart SSSD and retry the login with only the 1st server running to reproduce the issue.
According to the log snippet you send earlier, it is expected that
kinit
works fine because the authentication step 'pam_sss(sshd:auth)' was successful. This is the step which does a similar operation as kinit. The failure was in the next step 'pam_sss(sshd:access)' which is access control.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 19 feb 2019 alle ore 19:57 Sumit Bose via
FreeIPA-users <
freeipa-users@lists.fedorahosted.org> ha scritto:
On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via
FreeIPA-users
wrote:
Hi everybody.
I have just upgraded my cluster from FreeIPA 4.4.0-14 to
4.6.4-10.
All is good, logging via IPA credentials, HBAC and sudo rules are
working.
I have only a issue logging via SSH with AD credentials. Before
the
upgrade
all was working well.
I think that the trust is ok, because *kinit*, *ipa hbactest* and
*ipa
trustdomain-find* (on both ipa servers) are working well:
*[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM http://MYDOMAIN.COM Domain name: mydomain.com <
Domain NetBIOS name: MYDOMAIN Domain Security Identifier: S-1-5-21-3367759252-2451474351-126822339 Domain enabled: True----------------------------Number of entries returned 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com --host=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comService: sshd--------------------Access granted: True--------------------
Matched
rules: allow_ad_ipa_admins Not matched rules:
allow_ad_ipa_apps Not
matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit morgan.marodin@mydomain.com <morgan.marodin@mydomain.com
Password
for
morgan.marodin@mydomain.com morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]#
klistTicket
cache:
KEYRING:persistent:0:0Default principal:
morgan.marodin@MYDOMAIN.COM
morgan.marodin@MYDOMAIN.COMValid starting Expires Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM
renew
until 02/20/2019 17:55:18*
This is the error log:
*[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication
success;
logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb
19
18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account):
Access
denied
for user morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>:
6
(Permission denied)
This is returned by SSSD, please add debug_level=9 to the
[domain/...]
section of sssd.conf, restart, SSSD and try to login again. In the domain log you should find the evaluation of the HBAC rules which
might
explain why access was denied.
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: User account has expired for morgan.marodin@mydomain.com morgan.marodin@mydomain.com from 192.168.100.252
I'm not sure where this message comes from. I had a short look at
the
ssh and PAM source code, but so far didn't find a matching
messages.
bye, Sumit
Feb 19 18:03:21 mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted
request
104*
It seems a problem with pam and sssd. Do you have any suggestions?
Thanks, bye. Morgan
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA group *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in Active Directory. I tested the *id morgan.marodin@mydomain.com morgan.marodin@mydomain.com* command both in the client and the server, they differ only for the last part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets all group memberships from the server and it looks like the server once in a while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections on an IPA server and restart SSSD. Then please try to reproduce the state where ad_ipa_admins is missing. For this you can try to restart SSSD and call the id command afterwards or calling 'sss_cache -E' to invalidate the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
But the same client, as said last time, sometimes works correctly, please see these logs captured doing a SSH connection with the AD credential, after cleaning manually the sssd cache of the client:
*[root@mlv-testipa01 ~]# systemctl stop sssd ; rm -rf /var/lib/sss/db/* ; systemctl start sssd[root@mlv-testipa01 ~]# tail -f /var/log/sssd/*log | grep -i allow(Mon Feb 25 15:35:41 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=ipa,dc=mydomain,dc=com][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(memberHost=fqdn=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.com,cn=computers,cn=accounts,dc=ipa,dc=mydomain,dc=com)))](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(memberHost=fqdn=mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.com,cn=computers,cn=accounts,dc=ipa,dc=mydomain,dc=com)))][cn=hbac,dc=ipa,dc=mydomain,dc=com].(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x2000): Added non-POSIX group [ipa_it_mysite] to rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x2000): Added POSIX group [ad_ipa_admins@ipa.mydomain.com ad_ipa_admins@ipa.mydomain.com] to rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x2000): Added service [sshd] to rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ipa_it_mysite] [ENABLED]:(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_evaluate] (0x0100): The rule [allow_ipa_it_mysite] did not match.(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ad_ipa_admins] [ENABLED]:(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_evaluate] (0x0100): ALLOWED by rule [allow_ad_ipa_admins].(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap]*
So it's a strange behaviour because sometimes it worked and sometimes not. Which logs shoul be useful now?
Please let me know, thanks
Il giorno lun 25 feb 2019 alle ore 09:45 Sumit Bose sbose@redhat.com ha scritto:
On Mon, Feb 25, 2019 at 09:02:30AM +0100, Morgan Marodin wrote:
No, it's not true. It's random ... it not depends (maybe) from the
server.
You can find attached the debug logs from the test client, thanks
Hi,
at the end of the logs you can see the evaluation of the HBAC rules:
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_evaluate] (0x0100): [< hbac_evaluate() (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): REQUEST: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service [sshd] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user [morgan.marodin] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost [ mlv-testipa01.ipa.mydomain.com] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost [192.168.100.252] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): request time 2019-02-21 16:04:23 (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ipa_it_mysite] [ENABLED]: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): services: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): users: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_names (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_groups: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): [ipa_it_mysite] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): targethosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): srchosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_evaluate] (0x0100): The rule [allow_ipa_it_mysite] did not match.
......
The allow_ipa_it_mysite and all other rules do not match because
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none)
Earlier in the logs, when the group memberships of the user are looked up:
(Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): Received [7] groups in group list from IPA Server (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [morgan.marodin@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [local proxy exclusion@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite signature@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite users@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [ipa admins@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite it@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [domain users@mydomain.com].
there are only groups from the AD domain and the IPA group memberships are missing.
I would expect that 'id morgan.marodin@mydomain.com' only returns the groups listed above both on the client and on the server. Since the client gets the group-memberships from the server the next step would be to check the server logs.
For this please call 'sss_cache -E' on the server to invalidate the cache on the server and then 'id morgan.marodin@mydomain.com' on the server and send the logs covering the time of the id request. Please do not forget to set debug_level=9 in the [nss] and [domain/...] sections on the IPA server.
bye, Sumit
Il giorno gio 21 feb 2019 alle ore 16:01 Sumit Bose via FreeIPA-users < freeipa-users@lists.fedorahosted.org> ha scritto:
On Thu, Feb 21, 2019 at 03:47:15PM +0100, Morgan Marodin via
FreeIPA-users
wrote:
I did some tests, because some times SSH logins worked ... and
sometimes
not.
It seems that the problem is not client side:
- if I stop the 1st IPA server I'm able to login via SSH via AD
credentials
- if I stop the 2nd one (after started the other one, naturally) the
issue
appears again
With only the issued server started the I'm able to do a *kinit*
correctly.
What could I check server side?
I think it would be better to check the SSSD logs on the client side. Please add debug_level=9 to the [pam] and [domain/...] sections of sssd.conf, restart SSSD and retry the login with only the 1st server running to reproduce the issue.
According to the log snippet you send earlier, it is expected that
kinit
works fine because the authentication step 'pam_sss(sshd:auth)' was successful. This is the step which does a similar operation as kinit. The failure was in the next step 'pam_sss(sshd:access)' which is access control.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 19 feb 2019 alle ore 19:57 Sumit Bose via
FreeIPA-users <
freeipa-users@lists.fedorahosted.org> ha scritto:
On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via
FreeIPA-users
wrote: > Hi everybody. > > I have just upgraded my cluster from FreeIPA 4.4.0-14 to
4.6.4-10.
> All is good, logging via IPA credentials, HBAC and sudo rules are working. > I have only a issue logging via SSH with AD credentials. Before
the
upgrade > all was working well. > > I think that the trust is ok, because *kinit*, *ipa hbactest* and
*ipa
> trustdomain-find* (on both ipa servers) are working well: > > > > > > > > > > > > > > > > > > > > > > > > > > > *[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM > http://MYDOMAIN.COM Domain name: mydomain.com <
> Domain NetBIOS name: MYDOMAIN Domain Security Identifier: > S-1-5-21-3367759252-2451474351-126822339 Domain enabled: > True----------------------------Number of entries returned > 1----------------------------[root@mlv-ipasrv01 ~]# ipa hbactest > --user=morgan.marodin@mydomain.com morgan.marodin@mydomain.com > --host=mlv-testipa01.ipa.mydomain.com > http://mlv-testipa01.ipa.mydomain.comService: > sshd--------------------Access granted: True--------------------
Matched
> rules: allow_ad_ipa_admins Not matched rules:
allow_ad_ipa_apps Not
> matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]# kinit > morgan.marodin@mydomain.com <morgan.marodin@mydomain.com
Password
for
> morgan.marodin@mydomain.com > morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]#
klistTicket
cache:
> KEYRING:persistent:0:0Default principal:
morgan.marodin@MYDOMAIN.COM
> morgan.marodin@MYDOMAIN.COMValid starting Expires > Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 > krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM renew > until 02/20/2019 17:55:18* > > This is the error log: > > > > > *[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19 18:03:21 > mlv-testipa01 sshd[378408]: pam_sss(sshd:auth): authentication
success;
> logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 > user=morgan.marodin@mydomain.com morgan.marodin@mydomain.comFeb
19
> 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account):
Access
denied
> for user morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>:
6
> (Permission denied)
This is returned by SSSD, please add debug_level=9 to the
[domain/...]
section of sssd.conf, restart, SSSD and try to login again. In the domain log you should find the evaluation of the HBAC rules which
might
explain why access was denied.
> Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: > User account has expired for morgan.marodin@mydomain.com > morgan.marodin@mydomain.com from 192.168.100.252
I'm not sure where this message comes from. I had a short look at
the
ssh and PAM source code, but so far didn't find a matching
messages.
bye, Sumit
> Feb 19 18:03:21 > mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted
request
104*
> > It seems a problem with pam and sssd. > Do you have any suggestions? > > Thanks, bye. > Morgan
> _______________________________________________ > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You can find attached a tar.gz file with the logs of the server and the testing client, captured after done a restart of the *sssd* daemon and a *sss_cache -E* command, on both parts. I sanitize all logs, a long work!
Please let me know, thanks
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose sbose@redhat.com ha scritto:
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA group *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in Active Directory. I tested the *id morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>*
command both in the client and the server, they differ only for the last part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets all group memberships from the server and it looks like the server once in a while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections on an IPA server and restart SSSD. Then please try to reproduce the state where ad_ipa_admins is missing. For this you can try to restart SSSD and call the id command afterwards or calling 'sss_cache -E' to invalidate the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
But the same client, as said last time, sometimes works correctly, please see these logs captured doing a SSH connection with the AD credential, after cleaning manually the sssd cache of the client:
*[root@mlv-testipa01 ~]# systemctl stop sssd ; rm -rf /var/lib/sss/db/*
;
systemctl start sssd[root@mlv-testipa01 ~]# tail -f /var/log/sssd/*log | grep -i allow(Mon Feb 25 15:35:41 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base:
[cn=hbac,dc=ipa,dc=mydomain,dc=com][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(memberHost=fqdn= mlv-testipa01.ipa.mydomain.com
<http://mlv-testipa01.ipa.mydomain.com ,cn=computers,cn=accounts,dc=ipa,dc=mydomain,dc=com)))](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x0400):
calling
ldap_search_ext with
[(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(accessRuleType=allow)(|(hostCategory=all)(memberHost=fqdn= mlv-testipa01.ipa.mydomain.com
<http://mlv-testipa01.ipa.mydomain.com ,cn=computers,cn=accounts,dc=ipa,dc=mydomain,dc=com)))][cn=hbac,dc=ipa,dc=mydomain,dc=com].(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing
rule
[allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[
ipa.mydomain.com
http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000):
Processing
users for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x2000): Added non-POSIX group [ipa_it_mysite] to rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[
ipa.mydomain.com
http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_ipa_it_mysite](Mon Feb 25
15:36:23
- [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_ipa_it_mysite](Mon Feb 25 15:36:23 2019) [sssd[be[
ipa.mydomain.com
http://ipa.mydomain.com]]] [hbac_attrs_to_rule] (0x1000): Processing
rule
[allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[
ipa.mydomain.com
http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000):
Processing
users for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x2000): Added POSIX group [ad_ipa_admins@ipa.mydomain.com ad_ipa_admins@ipa.mydomain.com] to
rule
[allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[
ipa.mydomain.com
http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _ad_ipa_admins](Mon Feb 25
15:36:23
- [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[
ipa.mydomain.com
http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_ad_ipa_admins](Mon Feb 25
15:36:23
- [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]]
[hbac_attrs_to_rule] (0x1000): Processing rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allo _bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_service_attrs_to_rule] (0x2000): Added service [sshd] to rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_bexec](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ipa_it_mysite] [ENABLED]:(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_evaluate] (0x0100): The rule [allow_ipa_it_mysite] did not match.(Mon Feb 25
15:36:23
- [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]]
[hbac_rule_debug_print] (0x2000): RULE [allow_ad_ipa_admins] [ENABLED]:(Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [hbac_evaluate] (0x0100): ALLOWED by rule [allow_ad_ipa_admins].(Mon Feb 25 15:36:23 2019) [sssd[be[
ipa.mydomain.com
http://ipa.mydomain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_ad_ipa_admins](Mon Feb 25 15:36:23 2019) [sssd[be[ipa.mydomain.com http://ipa.mydomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap]*
So it's a strange behaviour because sometimes it worked and sometimes
not.
Which logs shoul be useful now?
Please let me know, thanks
Il giorno lun 25 feb 2019 alle ore 09:45 Sumit Bose sbose@redhat.com
ha
scritto:
On Mon, Feb 25, 2019 at 09:02:30AM +0100, Morgan Marodin wrote:
No, it's not true. It's random ... it not depends (maybe) from the
server.
You can find attached the debug logs from the test client, thanks
Hi,
at the end of the logs you can see the evaluation of the HBAC rules:
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]]
[hbac_evaluate]
(0x0100): [< hbac_evaluate() (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): REQUEST: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service [sshd] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): service_group
(none)
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user
[morgan.marodin]
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost [ mlv-testipa01.ipa.mydomain.com] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): targethost_group (none) (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost [192.168.100.252] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): srchost_group
(none)
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_req_debug_print] (0x2000): request time 2019-02-21 16:04:23 (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): RULE [allow_ipa_it_mysite]
[ENABLED]:
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): services: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1]
[ALL]
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): users: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0]
[NONE]
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_names
(none)
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): users_groups: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): [ipa_it_mysite] (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): targethosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1]
[ALL]
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_debug_print] (0x2000): srchosts: (Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_rule_element_debug_print] (0x2000): category [0x1]
[ALL]
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]]
[hbac_evaluate]
(0x0100): The rule [allow_ipa_it_mysite] did not match.
......
The allow_ipa_it_mysite and all other rules do not match because
(Thu Feb 21 16:04:23 2019) [sssd[be[ipa.mydomain.com]]] [hbac_request_element_debug_print] (0x2000): user_group (none)
Earlier in the logs, when the group memberships of the user are looked
up:
(Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): Received [7] groups in group list
from
IPA Server (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [morgan.marodin@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [local proxy exclusion@mydomain.com
].
(Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite signature@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite users@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [ipa admins@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [mysite it@mydomain.com]. (Thu Feb 21 16:04:13 2019) [sssd[be[ipa.mydomain.com]]] [ipa_s2n_get_user_done] (0x0400): [domain users@mydomain.com].
there are only groups from the AD domain and the IPA group memberships
are
missing.
I would expect that 'id morgan.marodin@mydomain.com' only returns the groups listed above both on the client and on the server. Since the client
gets
the group-memberships from the server the next step would be to check the server logs.
For this please call 'sss_cache -E' on the server to invalidate the
cache
on the server and then 'id morgan.marodin@mydomain.com' on the server and send the logs covering the time of the id request. Please do not forget to set debug_level=9 in the [nss] and [domain/...] sections on the IPA server.
bye, Sumit
Il giorno gio 21 feb 2019 alle ore 16:01 Sumit Bose via
FreeIPA-users <
freeipa-users@lists.fedorahosted.org> ha scritto:
On Thu, Feb 21, 2019 at 03:47:15PM +0100, Morgan Marodin via
FreeIPA-users
wrote:
I did some tests, because some times SSH logins worked ... and
sometimes
not.
It seems that the problem is not client side:
- if I stop the 1st IPA server I'm able to login via SSH via AD
credentials
- if I stop the 2nd one (after started the other one, naturally)
the
issue
appears again
With only the issued server started the I'm able to do a *kinit*
correctly.
What could I check server side?
I think it would be better to check the SSSD logs on the client
side.
Please add debug_level=9 to the [pam] and [domain/...] sections of sssd.conf, restart SSSD and retry the login with only the 1st
server
running to reproduce the issue.
According to the log snippet you send earlier, it is expected that
kinit
works fine because the authentication step 'pam_sss(sshd:auth)' was successful. This is the step which does a similar operation as
kinit.
The failure was in the next step 'pam_sss(sshd:access)' which is
access
control.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 19 feb 2019 alle ore 19:57 Sumit Bose via
FreeIPA-users <
freeipa-users@lists.fedorahosted.org> ha scritto:
> On Tue, Feb 19, 2019 at 06:19:18PM +0100, Morgan Marodin via
FreeIPA-users
> wrote: > > Hi everybody. > > > > I have just upgraded my cluster from FreeIPA 4.4.0-14 to
4.6.4-10.
> > All is good, logging via IPA credentials, HBAC and sudo
rules are
> working. > > I have only a issue logging via SSH with AD credentials.
Before
the
> upgrade > > all was working well. > > > > I think that the trust is ok, because *kinit*, *ipa
hbactest* and
*ipa
> > trustdomain-find* (on both ipa servers) are working well: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *[root@mlv-ipasrv01 ~]# ipa trustdomain-find MYDOMAIN.COM > > http://MYDOMAIN.COM Domain name: mydomain.com <
> > Domain NetBIOS name: MYDOMAIN Domain Security Identifier: > > S-1-5-21-3367759252-2451474351-126822339 Domain enabled: > > True----------------------------Number of entries returned > > 1----------------------------[root@mlv-ipasrv01 ~]# ipa
hbactest
> > --user=morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>
> > --host=mlv-testipa01.ipa.mydomain.com > > http://mlv-testipa01.ipa.mydomain.comService: > > sshd--------------------Access granted:
True--------------------
Matched
> > rules: allow_ad_ipa_admins Not matched rules:
allow_ad_ipa_apps Not
> > matched rules: allow_ipa_it_mysite[root@mlv-testipa01 ~]#
kinit
> > morgan.marodin@mydomain.com <morgan.marodin@mydomain.com
Password
for
> > morgan.marodin@mydomain.com > > morgan.marodin@mydomain.com:[root@mlv-testipa01 ~]#
klistTicket
cache:
> > KEYRING:persistent:0:0Default principal:
morgan.marodin@MYDOMAIN.COM
> > morgan.marodin@MYDOMAIN.COMValid starting Expires > > Service principal02/19/2019 17:55:23 02/20/2019 03:55:23 > > krbtgt/MYDOMAIN.COM@MYDOMAIN.COM MYDOMAIN.COM@MYDOMAIN.COM > renew > > until 02/20/2019 17:55:18* > > > > This is the error log: > > > > > > > > > > *[root@mlv-testipa01 ~]# tail -f /var/log/secureFeb 19
18:03:21
> > mlv-testipa01 sshd[378408]: pam_sss(sshd:auth):
authentication
success;
> > logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.252 > > user=morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>Feb
19
> > 18:03:21 mlv-testipa01 sshd[378408]: pam_sss(sshd:account):
Access
denied
> > for user morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>:
6
> > (Permission denied) > > This is returned by SSSD, please add debug_level=9 to the
[domain/...]
> section of sssd.conf, restart, SSSD and try to login again. In
the
> domain log you should find the evaluation of the HBAC rules
which
might
> explain why access was denied. > > > Feb 19 18:03:21 mlv-testipa01 sshd[378401]: error: PAM: > > User account has expired for morgan.marodin@mydomain.com > > morgan.marodin@mydomain.com from 192.168.100.252 > > I'm not sure where this message comes from. I had a short look
at
the
> ssh and PAM source code, but so far didn't find a matching
messages.
> > bye, > Sumit > > > Feb 19 18:03:21 > > mlv-testipa01 sshd[378401]: fatal: monitor_read: unpermitted
request
104*
> > > > It seems a problem with pam and sssd. > > Do you have any suggestions? > > > > Thanks, bye. > > Morgan > > > _______________________________________________ > > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org > > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: >
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
> _______________________________________________ > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: >
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
>
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You can find attached a tar.gz file with the logs of the server and the testing client, captured after done a restart of the *sssd* daemon and a *sss_cache -E* command, on both parts. I sanitized all logs, a long work!
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose sbose@redhat.com ha scritto:
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA group *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in Active Directory. I tested the *id morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>*
command both in the client and the server, they differ only for the last part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets all group memberships from the server and it looks like the server once in a while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections on an IPA server and restart SSSD. Then please try to reproduce the state where ad_ipa_admins is missing. For this you can try to restart SSSD and call the id command afterwards or calling 'sss_cache -E' to invalidate the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
Sorry, any news from my logs?
Please let me know, thanks. Morgan
Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin morgan@marodin.it ha scritto:
You can find attached a tar.gz file with the logs of the server and the testing client, captured after done a restart of the *sssd* daemon and a *sss_cache -E* command, on both parts. I sanitized all logs, a long work!
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose sbose@redhat.com ha scritto:
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA group *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in Active Directory. I tested the *id morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>*
command both in the client and the server, they differ only for the last part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets all group memberships from the server and it looks like the server once in a while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections on an IPA server and restart SSSD. Then please try to reproduce the state where ad_ipa_admins is missing. For this you can try to restart SSSD and call the id command afterwards or calling 'sss_cache -E' to invalidate the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote:
Sorry, any news from my logs?
sorry for the delay. What kind of server is 192.168.0.15? It looks like the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns 'Realm not local to KDC' when getting a request for this realm. Additionally it looks like it cannot decrypt IPA-AD cross-realm tickets.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin morgan@marodin.it ha scritto:
You can find attached a tar.gz file with the logs of the server and the testing client, captured after done a restart of the *sssd* daemon and a *sss_cache -E* command, on both parts. I sanitized all logs, a long work!
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose sbose@redhat.com ha scritto:
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA group *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in Active Directory. I tested the *id morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>*
command both in the client and the server, they differ only for the last part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets all group memberships from the server and it looks like the server once in a while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections on an IPA server and restart SSSD. Then please try to reproduce the state where ad_ipa_admins is missing. For this you can try to restart SSSD and call the id command afterwards or calling 'sss_cache -E' to invalidate the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
It's one of our local Domain Controller, in this site there is 2 DC. Could I try to delete and recreate the trust? Or do you have other suggestions?
Thanks
Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose sbose@redhat.com ha scritto:
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote:
Sorry, any news from my logs?
sorry for the delay. What kind of server is 192.168.0.15? It looks like the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns 'Realm not local to KDC' when getting a request for this realm. Additionally it looks like it cannot decrypt IPA-AD cross-realm tickets.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin <
morgan@marodin.it>
ha scritto:
You can find attached a tar.gz file with the logs of the server and the testing client, captured after done a restart of the *sssd* daemon and
a *sss_cache
-E* command, on both parts. I sanitized all logs, a long work!
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose sbose@redhat.com
ha
scritto:
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA
group
*ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in
Active
Directory. I tested the *id morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>*
command both in the client and the server, they differ only for the
last
part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets
all
group memberships from the server and it looks like the server once
in a
while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections on an IPA server and restart SSSD. Then please try to reproduce the state where ad_ipa_admins is missing. For this you can try to restart SSSD
and
call the id command afterwards or calling 'sss_cache -E' to invalidate the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
Sorry, could I try to delete and recreate the trust? Or do you have other suggestions?
Please let me know, thanks
Il giorno ven 1 mar 2019 alle ore 15:13 Morgan Marodin morgan@marodin.it ha scritto:
It's one of our local Domain Controller, in this site there is 2 DC. Could I try to delete and recreate the trust? Or do you have other suggestions?
Thanks
Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose sbose@redhat.com ha scritto:
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote:
Sorry, any news from my logs?
sorry for the delay. What kind of server is 192.168.0.15? It looks like the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns 'Realm not local to KDC' when getting a request for this realm. Additionally it looks like it cannot decrypt IPA-AD cross-realm tickets.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin <
morgan@marodin.it>
ha scritto:
You can find attached a tar.gz file with the logs of the server and
the
testing client, captured after done a restart of the *sssd* daemon
and a *sss_cache
-E* command, on both parts. I sanitized all logs, a long work!
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose sbose@redhat.com
ha
scritto:
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote:
The right HBAC is called *allow_ad_ipa_admins*, that match the IPA
group
*ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in
Active
Directory. I tested the *id morgan.marodin@mydomain.com <
morgan.marodin@mydomain.com>*
command both in the client and the server, they differ only for
the last
part *,219402407(ad_ipa_admins)*. I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets
all
group memberships from the server and it looks like the server once
in a
while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections
on
an IPA server and restart SSSD. Then please try to reproduce the
state
where ad_ipa_admins is missing. For this you can try to restart SSSD
and
call the id command afterwards or calling 'sss_cache -E' to
invalidate
the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
On Thu, Mar 07, 2019 at 09:15:30AM +0100, Morgan Marodin wrote:
Sorry, could I try to delete and recreate the trust? Or do you have other suggestions?
Please let me know, thanks
Il giorno ven 1 mar 2019 alle ore 15:13 Morgan Marodin morgan@marodin.it ha scritto:
It's one of our local Domain Controller, in this site there is 2 DC. Could I try to delete and recreate the trust? Or do you have other suggestions?
Hi,
I think recreate the trust won't help. It looks like a DNS issue. Please check if
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COM
or
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COM
return this DC or any other AD DCs. Only IPA servers should be returned here.
bye, Sumit
Thanks
Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose sbose@redhat.com ha scritto:
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote:
Sorry, any news from my logs?
sorry for the delay. What kind of server is 192.168.0.15? It looks like the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns 'Realm not local to KDC' when getting a request for this realm. Additionally it looks like it cannot decrypt IPA-AD cross-realm tickets.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin <
morgan@marodin.it>
ha scritto:
You can find attached a tar.gz file with the logs of the server and
the
testing client, captured after done a restart of the *sssd* daemon
and a *sss_cache
-E* command, on both parts. I sanitized all logs, a long work!
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose sbose@redhat.com
ha
scritto:
On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote: > The right HBAC is called *allow_ad_ipa_admins*, that match the IPA
group
> *ad_ipa_admins*, that is trusted with the group '*IPA Admins*' in
Active
> Directory. > I tested the *id morgan.marodin@mydomain.com < morgan.marodin@mydomain.com>* > command both in the client and the server, they differ only for
the last
> part *,219402407(ad_ipa_admins)*. > I can see it in the client, not in the server.
That explains the changing behaviour on the client. The client gets
all
group memberships from the server and it looks like the server once
in a
while has issues to add the IPA group memberships to AD users.
Please add now debug_level=9 to the [nss] and [domain/...] sections
on
an IPA server and restart SSSD. Then please try to reproduce the
state
where ad_ipa_admins is missing. For this you can try to restart SSSD
and
call the id command afterwards or calling 'sss_cache -E' to
invalidate
the cached data before calling id.
If you change sssd.conf on the servers it would be helpful to see a (sanitized) version of sssd.conf as well.
bye, Sumit
Hi.
*[root@mlv-testipa01 ~]# host -t SRV _kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM_kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com._kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t SRV _kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM_kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com._kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t any mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.commlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com has address 192.168.0.65[root@mlv-testipa01 ~]# host -t any mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.commlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has address 192.168.0.66mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 1 1 1A1F9D66E9B156AA14A6739C46252814163D7DB2mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 1 2 7BCDACE8C28B624E938D646791734C740F0833A0221E1B573D323EC4 A726FB07mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 3 2 BE4850443507A7B6E174576ACDAEBA6D3839C9476BFBAA09B0753D75 F7C62DC1mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 3 1 32ADAF67104C0A6ADF94446B3BCB5235550C9D14*
And this is the version and the *sssd.conf* of the test client:
*[root@mlv-testipa01 ~]# sssd --version1.16.2*
*[root@mlv-testipa01 ~]# cat /etc/sssd/sssd.conf*
*[domain/ipa.mydomain.com http://ipa.mydomain.com]debug_level = 9cache_credentials = Truekrb5_store_password_if_offline = Trueipa_domain = ipa.mydomain.com http://ipa.mydomain.comid_provider = ipaauth_provider = ipaaccess_provider = ipaipa_hostname = mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comchpass_provider = ipaipa_server = _srv_, mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.comldap_tls_cacert = /etc/ipa/ca.crt#dns_discovery_domain = mysite._sites.mydomain.com http://sites.mydomain.com[sssd]services = nss, sudo, pam, sshdomains = ipa.mydomain.com http://ipa.mydomain.com[nss]homedir_substring = /homeoverride_shell = /bin/bash[pam][sudo][autofs][ssh][pac][ifp][secrets][session_recording]*
Any other check regarding DNS? Thanks, bye
Il giorno gio 7 mar 2019 alle ore 12:13 Sumit Bose sbose@redhat.com ha scritto:
On Thu, Mar 07, 2019 at 09:15:30AM +0100, Morgan Marodin wrote:
Sorry, could I try to delete and recreate the trust? Or do you have other suggestions?
Please let me know, thanks
Il giorno ven 1 mar 2019 alle ore 15:13 Morgan Marodin <
morgan@marodin.it>
ha scritto:
It's one of our local Domain Controller, in this site there is 2 DC. Could I try to delete and recreate the trust? Or do you have other suggestions?
Hi,
I think recreate the trust won't help. It looks like a DNS issue. Please check if
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMor
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMreturn this DC or any other AD DCs. Only IPA servers should be returned here.
bye, Sumit
Thanks
Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose sbose@redhat.com
ha
scritto:
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote:
Sorry, any news from my logs?
sorry for the delay. What kind of server is 192.168.0.15? It looks
like
the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns 'Realm not local to KDC' when getting a request for this realm. Additionally it looks like it cannot decrypt IPA-AD cross-realm
tickets.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin <
morgan@marodin.it>
ha scritto:
You can find attached a tar.gz file with the logs of the server
and
the
testing client, captured after done a restart of the *sssd* daemon
and a *sss_cache
-E* command, on both parts. I sanitized all logs, a long work!
Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose <
sbose@redhat.com>
ha
scritto:
> On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote: > > The right HBAC is called *allow_ad_ipa_admins*, that match the
IPA
group
> > *ad_ipa_admins*, that is trusted with the group '*IPA Admins*'
in
Active
> > Directory. > > I tested the *id morgan.marodin@mydomain.com < > morgan.marodin@mydomain.com>* > > command both in the client and the server, they differ only for
the last
> > part *,219402407(ad_ipa_admins)*. > > I can see it in the client, not in the server. > > > That explains the changing behaviour on the client. The client
gets
all
> group memberships from the server and it looks like the server
once
in a
> while has issues to add the IPA group memberships to AD users. > > Please add now debug_level=9 to the [nss] and [domain/...]
sections
on
> an IPA server and restart SSSD. Then please try to reproduce the
state
> where ad_ipa_admins is missing. For this you can try to restart
SSSD
and
> call the id command afterwards or calling 'sss_cache -E' to
invalidate
> the cached data before calling id. > > If you change sssd.conf on the servers it would be helpful to
see a
> (sanitized) version of sssd.conf as well. > > > bye, > Sumit >
Another strange behaviour ...
From 1st IPA server:
*[root@mlv-ipa01 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com)* From 2nd IPA server:
*[root@mlv-ipa02 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com),217403007(ad_ipa_admins)* From the test IPA client:
*[root@mlv-testipa01 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.com uid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com),217403007(ad_ipa_admins)* From another IPA client (with the same issue):
*[root@mlv-box02 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com)*
As you can see the *217403007(ad_ipa_admins)* is given back only from some server, not all, and the match is done via HBAC in that group.
Bye
Il giorno gio 7 mar 2019 alle ore 15:38 Morgan Marodin morgan@marodin.it ha scritto:
Hi.
*[root@mlv-testipa01 ~]# host -t SRV _kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM_kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com._kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t SRV _kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM_kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com._kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t any mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.commlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com has address 192.168.0.65[root@mlv-testipa01 ~]# host -t any mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.commlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has address 192.168.0.66mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 1 1 1A1F9D66E9B156AA14A6739C46252814163D7DB2mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 1 2 7BCDACE8C28B624E938D646791734C740F0833A0221E1B573D323EC4 A726FB07mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 3 2 BE4850443507A7B6E174576ACDAEBA6D3839C9476BFBAA09B0753D75 F7C62DC1mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 3 1 32ADAF67104C0A6ADF94446B3BCB5235550C9D14*
And this is the version and the *sssd.conf* of the test client:
*[root@mlv-testipa01 ~]# sssd --version1.16.2*
*[root@mlv-testipa01 ~]# cat /etc/sssd/sssd.conf*
*[domain/ipa.mydomain.com http://ipa.mydomain.com]debug_level = 9cache_credentials = Truekrb5_store_password_if_offline = Trueipa_domain = ipa.mydomain.com http://ipa.mydomain.comid_provider = ipaauth_provider = ipaaccess_provider = ipaipa_hostname = mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comchpass_provider = ipaipa_server = _srv_, mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.comldap_tls_cacert = /etc/ipa/ca.crt#dns_discovery_domain = mysite._sites.mydomain.com http://sites.mydomain.com[sssd]services = nss, sudo, pam, sshdomains = ipa.mydomain.com http://ipa.mydomain.com[nss]homedir_substring = /homeoverride_shell = /bin/bash[pam][sudo][autofs][ssh][pac][ifp][secrets][session_recording]*
Any other check regarding DNS? Thanks, bye
Il giorno gio 7 mar 2019 alle ore 12:13 Sumit Bose sbose@redhat.com ha scritto:
On Thu, Mar 07, 2019 at 09:15:30AM +0100, Morgan Marodin wrote:
Sorry, could I try to delete and recreate the trust? Or do you have other suggestions?
Please let me know, thanks
Il giorno ven 1 mar 2019 alle ore 15:13 Morgan Marodin <
morgan@marodin.it>
ha scritto:
It's one of our local Domain Controller, in this site there is 2 DC. Could I try to delete and recreate the trust? Or do you have other suggestions?
Hi,
I think recreate the trust won't help. It looks like a DNS issue. Please check if
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMor
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMreturn this DC or any other AD DCs. Only IPA servers should be returned here.
bye, Sumit
Thanks
Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose sbose@redhat.com
ha
scritto:
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote:
Sorry, any news from my logs?
sorry for the delay. What kind of server is 192.168.0.15? It looks
like
the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns 'Realm not local to KDC' when getting a request for this realm. Additionally it looks like it cannot decrypt IPA-AD cross-realm
tickets.
bye, Sumit
Please let me know, thanks. Morgan
Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin <
morgan@marodin.it>
ha scritto:
> You can find attached a tar.gz file with the logs of the server
and
the
> testing client, captured after done a restart of the *sssd*
daemon
and a *sss_cache
> -E* command, on both parts. > I sanitized all logs, a long work! > > Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose <
sbose@redhat.com>
ha
> scritto: > >> On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote: >> > The right HBAC is called *allow_ad_ipa_admins*, that match
the IPA
group
>> > *ad_ipa_admins*, that is trusted with the group '*IPA
Admins*' in
Active
>> > Directory. >> > I tested the *id morgan.marodin@mydomain.com < >> morgan.marodin@mydomain.com>* >> > command both in the client and the server, they differ only
for
the last
>> > part *,219402407(ad_ipa_admins)*. >> > I can see it in the client, not in the server. >> >> >> That explains the changing behaviour on the client. The client
gets
all
>> group memberships from the server and it looks like the server
once
in a
>> while has issues to add the IPA group memberships to AD users. >> >> Please add now debug_level=9 to the [nss] and [domain/...]
sections
on
>> an IPA server and restart SSSD. Then please try to reproduce the
state
>> where ad_ipa_admins is missing. For this you can try to restart
SSSD
and
>> call the id command afterwards or calling 'sss_cache -E' to
invalidate
>> the cached data before calling id. >> >> If you change sssd.conf on the servers it would be helpful to
see a
>> (sanitized) version of sssd.conf as well. >> >> >> bye, >> Sumit >> >
On Thu, Mar 07, 2019 at 04:10:09PM +0100, Morgan Marodin wrote:
Another strange behaviour ...
From 1st IPA server:
*[root@mlv-ipa01 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com)*
Getting the group memberships of a user is a multi step process and SSSD on the IPA server currently saves the memberships it got for the user from AD into the cache before it tries to lookup the memberships in IPA groups from the IPA server. If there is an issue during this step the user will only have the AD memberships.
Are the IPA groups always missing on this server? If there already is a higher debug_level set in the [domain/..] section on this server please send the SSSD logs. If not please add debug_level=9 at least to the [domain/...] section and restart SSSD. The run the id command again on the server. If the IPA group is still missing please send the logs directly. Otherwise please wait until the group got lost.
You might be able to trigger the loss by invalidation the cache with 'sss_cache -E' and running lookups for this group with 'getent group ad_ipa_admins' or id lookups for other member of this groups.
bye, Sumit
From 2nd IPA server:
*[root@mlv-ipa02 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com),217403007(ad_ipa_admins)* From the test IPA client:
*[root@mlv-testipa01 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.com uid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com),217403007(ad_ipa_admins)* From another IPA client (with the same issue):
*[root@mlv-box02 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature pedon@mydomain.com pedon@mydomain.com),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa admins@mydomain.com admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com)*
As you can see the *217403007(ad_ipa_admins)* is given back only from some server, not all, and the match is done via HBAC in that group.
Bye
Il giorno gio 7 mar 2019 alle ore 15:38 Morgan Marodin morgan@marodin.it ha scritto:
Hi.
*[root@mlv-testipa01 ~]# host -t SRV _kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM_kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com._kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t SRV _kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM_kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com._kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t any mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.commlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com has address 192.168.0.65[root@mlv-testipa01 ~]# host -t any mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.commlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has address 192.168.0.66mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 1 1 1A1F9D66E9B156AA14A6739C46252814163D7DB2mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 1 2 7BCDACE8C28B624E938D646791734C740F0833A0221E1B573D323EC4 A726FB07mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 3 2 BE4850443507A7B6E174576ACDAEBA6D3839C9476BFBAA09B0753D75 F7C62DC1mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 3 1 32ADAF67104C0A6ADF94446B3BCB5235550C9D14*
And this is the version and the *sssd.conf* of the test client:
*[root@mlv-testipa01 ~]# sssd --version1.16.2*
*[root@mlv-testipa01 ~]# cat /etc/sssd/sssd.conf*
*[domain/ipa.mydomain.com http://ipa.mydomain.com]debug_level = 9cache_credentials = Truekrb5_store_password_if_offline = Trueipa_domain = ipa.mydomain.com http://ipa.mydomain.comid_provider = ipaauth_provider = ipaaccess_provider = ipaipa_hostname = mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comchpass_provider = ipaipa_server = _srv_, mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.comldap_tls_cacert = /etc/ipa/ca.crt#dns_discovery_domain = mysite._sites.mydomain.com http://sites.mydomain.com[sssd]services = nss, sudo, pam, sshdomains = ipa.mydomain.com http://ipa.mydomain.com[nss]homedir_substring = /homeoverride_shell = /bin/bash[pam][sudo][autofs][ssh][pac][ifp][secrets][session_recording]*
Any other check regarding DNS? Thanks, bye
Il giorno gio 7 mar 2019 alle ore 12:13 Sumit Bose sbose@redhat.com ha scritto:
On Thu, Mar 07, 2019 at 09:15:30AM +0100, Morgan Marodin wrote:
Sorry, could I try to delete and recreate the trust? Or do you have other suggestions?
Please let me know, thanks
Il giorno ven 1 mar 2019 alle ore 15:13 Morgan Marodin <
morgan@marodin.it>
ha scritto:
It's one of our local Domain Controller, in this site there is 2 DC. Could I try to delete and recreate the trust? Or do you have other suggestions?
Hi,
I think recreate the trust won't help. It looks like a DNS issue. Please check if
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMor
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMreturn this DC or any other AD DCs. Only IPA servers should be returned here.
bye, Sumit
Thanks
Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose sbose@redhat.com
ha
scritto:
On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote: > Sorry, any news from my logs?
sorry for the delay. What kind of server is 192.168.0.15? It looks
like
the client assumes it is a KDC for IPA.MYDOMAIN.COM but it returns 'Realm not local to KDC' when getting a request for this realm. Additionally it looks like it cannot decrypt IPA-AD cross-realm
tickets.
bye, Sumit
> > Please let me know, thanks. > Morgan > > Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin < morgan@marodin.it> > ha scritto: > > > You can find attached a tar.gz file with the logs of the server
and
the > > testing client, captured after done a restart of the *sssd*
daemon
and a *sss_cache > > -E* command, on both parts. > > I sanitized all logs, a long work! > > > > Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose <
sbose@redhat.com>
ha > > scritto: > > > >> On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin wrote: > >> > The right HBAC is called *allow_ad_ipa_admins*, that match
the IPA
group > >> > *ad_ipa_admins*, that is trusted with the group '*IPA
Admins*' in
Active > >> > Directory. > >> > I tested the *id morgan.marodin@mydomain.com < > >> morgan.marodin@mydomain.com>* > >> > command both in the client and the server, they differ only
for
the last > >> > part *,219402407(ad_ipa_admins)*. > >> > I can see it in the client, not in the server. > >> > >> > >> That explains the changing behaviour on the client. The client
gets
all > >> group memberships from the server and it looks like the server
once
in a > >> while has issues to add the IPA group memberships to AD users. > >> > >> Please add now debug_level=9 to the [nss] and [domain/...]
sections
on > >> an IPA server and restart SSSD. Then please try to reproduce the state > >> where ad_ipa_admins is missing. For this you can try to restart
SSSD
and > >> call the id command afterwards or calling 'sss_cache -E' to invalidate > >> the cached data before calling id. > >> > >> If you change sssd.conf on the servers it would be helpful to
see a
> >> (sanitized) version of sssd.conf as well. > >> > >> > >> bye, > >> Sumit > >> > >
-- Morgan Marodin email: morgan@marodin.it mobile: +39.3477829069
Yes, this IPA group was always missing in the 1st IPA server, and another IPA group was missing in the 2nd IPA server. After executing *systemctl stop sssd ; sss_cache -E ; rm -rf /var/lib/sss/db/* ; systemctl start sssd* on each server I can see both IPA groups on both servers. I can't explain this, only executing *sss_cache -E* the problem persisted, I had to delete cache files too, and to restart services.
Then I tried to do the same procedure several times, but it seems that I can see always correct groups doing a *id username@mydomain.com username@mydomain.com* command. I tried to do a ssh connection using my AD credential on all my IPA clients and now it works.
So, do you think the issue is solved now? Only a cache problem after the update of the release of the two servers?
Thanks, bye
Il giorno ven 8 mar 2019 alle ore 11:50 Sumit Bose sbose@redhat.com ha scritto:
On Thu, Mar 07, 2019 at 04:10:09PM +0100, Morgan Marodin wrote:
Another strange behaviour ...
From 1st IPA server:
*[root@mlv-ipa01 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(
morgan.marodin@mydomain.com
morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature mycompany@mydomain.com <mycompany@mydomain.com ),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa
admins@mydomain.com
admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com)*
Getting the group memberships of a user is a multi step process and SSSD on the IPA server currently saves the memberships it got for the user from AD into the cache before it tries to lookup the memberships in IPA groups from the IPA server. If there is an issue during this step the user will only have the AD memberships.
Are the IPA groups always missing on this server? If there already is a higher debug_level set in the [domain/..] section on this server please send the SSSD logs. If not please add debug_level=9 at least to the [domain/...] section and restart SSSD. The run the id command again on the server. If the IPA group is still missing please send the logs directly. Otherwise please wait until the group got lost.
You might be able to trigger the loss by invalidation the cache with 'sss_cache -E' and running lookups for this group with 'getent group ad_ipa_admins' or id lookups for other member of this groups.
bye, Sumit
From 2nd IPA server:
*[root@mlv-ipa02 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(
morgan.marodin@mydomain.com
morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature mycompany@mydomain.com <mycompany@mydomain.com ),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa
admins@mydomain.com
admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com),217403007(ad_ipa_admins)* From the test IPA client:
*[root@mlv-testipa01 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.com uid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(
morgan.marodin@mydomain.com
morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature mycompany@mydomain.com <mycompany@mydomain.com ),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa
admins@mydomain.com
admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com),217403007(ad_ipa_admins)* From another IPA client (with the same issue):
*[root@mlv-box02 ~]# id morgan.marodin@mydomain.com morgan.marodin@mydomain.comuid=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com) gid=1143802726(
morgan.marodin@mydomain.com
morgan.marodin@mydomain.com) groups=1143802726(morgan.marodin@mydomain.com morgan.marodin@mydomain.com),1147803679(aaa local proxy exclusion@mydomain.com exclusion@mydomain.com),1147802790(mysite signature mycompany@mydomain.com <mycompany@mydomain.com ),1147801237(mysite users@mydomain.com users@mydomain.com),1147862761(ipa
admins@mydomain.com
admins@mydomain.com),1147801336(mysite it@mydomain.com it@mydomain.com),1147800813(domain users@mydomain.com users@mydomain.com)*
As you can see the *217403007(ad_ipa_admins)* is given back only from
some
server, not all, and the match is done via HBAC in that group.
Bye
Il giorno gio 7 mar 2019 alle ore 15:38 Morgan Marodin <
morgan@marodin.it>
ha scritto:
Hi.
*[root@mlv-testipa01 ~]# host -t SRV _kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM_kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com._kerberos._udp.IPA.MYDOMAIN.COM http://udp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t
SRV
_kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM_kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com._kerberos._tcp.IPA.MYDOMAIN.COM http://tcp.IPA.MYDOMAIN.COM has SRV record 0 100 88 mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com.[root@mlv-testipa01 ~]# host -t
any
mlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.commlv-ipa01.ipa.mydomain.com http://mlv-ipa01.ipa.mydomain.com has address 192.168.0.65[root@mlv-testipa01 ~]# host -t any
mlv-ipa02.ipa.mydomain.com
http://mlv-ipa02.ipa.mydomain.commlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has address 192.168.0.66mlv-ipa02.ipa.mydomain.com <
http://mlv-ipa02.ipa.mydomain.com%3E
has SSHFP record 1 1 1A1F9D66E9B156AA14A6739C46252814163D7DB2mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com has SSHFP record 1 2 7BCDACE8C28B624E938D646791734C740F0833A0221E1B573D323EC4 A726FB07mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com
has
SSHFP record 3 2
BE4850443507A7B6E174576ACDAEBA6D3839C9476BFBAA09B0753D75
F7C62DC1mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.com
has
SSHFP record 3 1 32ADAF67104C0A6ADF94446B3BCB5235550C9D14*
And this is the version and the *sssd.conf* of the test client:
*[root@mlv-testipa01 ~]# sssd --version1.16.2*
*[root@mlv-testipa01 ~]# cat /etc/sssd/sssd.conf*
*[domain/ipa.mydomain.com http://ipa.mydomain.com]debug_level = 9cache_credentials = Truekrb5_store_password_if_offline =
Trueipa_domain =
ipa.mydomain.com http://ipa.mydomain.comid_provider =
ipaauth_provider =
ipaaccess_provider = ipaipa_hostname = mlv-testipa01.ipa.mydomain.com http://mlv-testipa01.ipa.mydomain.comchpass_provider =
ipaipa_server =
_srv_, mlv-ipa02.ipa.mydomain.com http://mlv-ipa02.ipa.mydomain.comldap_tls_cacert = /etc/ipa/ca.crt#dns_discovery_domain = mysite._sites.mydomain.com http://sites.mydomain.com[sssd]services = nss, sudo, pam,
sshdomains =
ipa.mydomain.com http://ipa.mydomain.com[nss]homedir_substring = /homeoverride_shell =
/bin/bash[pam][sudo][autofs][ssh][pac][ifp][secrets][session_recording]*
Any other check regarding DNS? Thanks, bye
Il giorno gio 7 mar 2019 alle ore 12:13 Sumit Bose sbose@redhat.com
ha
scritto:
On Thu, Mar 07, 2019 at 09:15:30AM +0100, Morgan Marodin wrote:
Sorry, could I try to delete and recreate the trust? Or do you have other suggestions?
Please let me know, thanks
Il giorno ven 1 mar 2019 alle ore 15:13 Morgan Marodin <
morgan@marodin.it>
ha scritto:
It's one of our local Domain Controller, in this site there is 2
DC.
Could I try to delete and recreate the trust? Or do you have other suggestions?
Hi,
I think recreate the trust won't help. It looks like a DNS issue.
Please
check if
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMor
host -t SRV _kerberos._udp.IPA.MYDOMAIN.COMreturn this DC or any other AD DCs. Only IPA servers should be
returned
here.
bye, Sumit
Thanks
Il giorno ven 1 mar 2019 alle ore 11:13 Sumit Bose <
sbose@redhat.com>
ha
scritto:
> On Fri, Mar 01, 2019 at 09:07:26AM +0100, Morgan Marodin wrote: > > Sorry, any news from my logs? > > sorry for the delay. What kind of server is 192.168.0.15? It
looks
like
> the client assumes it is a KDC for IPA.MYDOMAIN.COM but it
returns
> 'Realm not local to KDC' when getting a request for this realm. > Additionally it looks like it cannot decrypt IPA-AD cross-realm
tickets.
> > bye, > Sumit > > > > > Please let me know, thanks. > > Morgan > > > > Il giorno mar 26 feb 2019 alle ore 11:56 Morgan Marodin < > morgan@marodin.it> > > ha scritto: > > > > > You can find attached a tar.gz file with the logs of the
server
and
> the > > > testing client, captured after done a restart of the *sssd*
daemon
> and a *sss_cache > > > -E* command, on both parts. > > > I sanitized all logs, a long work! > > > > > > Il giorno lun 25 feb 2019 alle ore 17:14 Sumit Bose <
sbose@redhat.com>
> ha > > > scritto: > > > > > >> On Mon, Feb 25, 2019 at 03:55:52PM +0100, Morgan Marodin
wrote:
> > >> > The right HBAC is called *allow_ad_ipa_admins*, that match
the IPA
> group > > >> > *ad_ipa_admins*, that is trusted with the group '*IPA
Admins*' in
> Active > > >> > Directory. > > >> > I tested the *id morgan.marodin@mydomain.com < > > >> morgan.marodin@mydomain.com>* > > >> > command both in the client and the server, they differ
only
for
> the last > > >> > part *,219402407(ad_ipa_admins)*. > > >> > I can see it in the client, not in the server. > > >> > > >> > > >> That explains the changing behaviour on the client. The
client
gets
> all > > >> group memberships from the server and it looks like the
server
once
> in a > > >> while has issues to add the IPA group memberships to AD
users.
> > >> > > >> Please add now debug_level=9 to the [nss] and [domain/...]
sections
> on > > >> an IPA server and restart SSSD. Then please try to
reproduce the
> state > > >> where ad_ipa_admins is missing. For this you can try to
restart
SSSD
> and > > >> call the id command afterwards or calling 'sss_cache -E' to > invalidate > > >> the cached data before calling id. > > >> > > >> If you change sssd.conf on the servers it would be helpful
to
see a
> > >> (sanitized) version of sssd.conf as well. > > >> > > >> > > >> bye, > > >> Sumit > > >> > > > >
freeipa-users@lists.fedorahosted.org
-
Morgan Marodin -
Sumit Bose