Hello all,
I'm wondering if anyone could help shed light on why IPA CLI commands fail for a trusted AD user, and why Web UI logins for the same user fail with the message "Your session has expired. Please re-login.", despite creating a view for the user via `ipa idoverrideuser-add 'Default Trust View' ad_user@ad_domain.com`. The symptoms appear almost identical to the post [0], except that the cli and Web UI were never working previously.
I am able to login via SSH (on a host with an HBAC configured), and able to `kinit` and obtain the appropriate tickets across the realms. I've configured the system accordingly, per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup.
I am running FreeIPA version 4.6.4 with a successful AD Trust (one way) using the range type "ipa-ad-trust-posix", both nodes completely re-provisioned (fresh installation purposes). SELinux is disabled, and the configuration IPA-wise is untouched, with the exception of enabling debugging and editing krb5.conf per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5...
I've attached Apache logs referencing the Web UI and from the console. From what I have found online, it should be possible to allow an AD user to login to Web UI and ipa CLI commands should function, too. All IPA services are running and have been restarted, just in case something was "stuck". The interesting entries within the logs: (Failed to unseal session data!, GSSapiImpersonate not On) seem to be red herrings.
Thanks for any assistance!
John DeSantis
[0] https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
Hello all,
I'm wondering if anyone could help shed light on why IPA CLI commands fail for a trusted AD user, and why Web UI logins for the same user fail with the message "Your session has expired. Please re-login.", despite creating a view for the user via `ipa idoverrideuser-add 'Default Trust View' ad_user@ad_domain.com`. The symptoms appear almost identical to the post [0], except that the cli and Web UI were never working previously.
Enable debugging for IPA server framework by creating a file /etc/ipa/server.conf with the following content:
-------- [global] debug=True --------
Restart httpd and try again. Then collect logs and show that access attempt. The logs you attached so far only contain Apache modules' debugging information, not IPA framework's one.
I am able to login via SSH (on a host with an HBAC configured), and able to `kinit` and obtain the appropriate tickets across the realms. I've configured the system accordingly, per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup.
I am running FreeIPA version 4.6.4 with a successful AD Trust (one way) using the range type "ipa-ad-trust-posix", both nodes completely re-provisioned (fresh installation purposes). SELinux is disabled, and the configuration IPA-wise is untouched, with the exception of enabling debugging and editing krb5.conf per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5...
I've attached Apache logs referencing the Web UI and from the console. From what I have found online, it should be possible to allow an AD user to login to Web UI and ipa CLI commands should function, too. All IPA services are running and have been restarted, just in case something was "stuck". The interesting entries within the logs: (Failed to unseal session data!, GSSapiImpersonate not On) seem to be red herrings.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6 for that. Web UI / CLI administration with AD users is only available in RHEL 8.0 beta.
# /var/log/krb5kdc.log
Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): closing down fd 11 Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): closing down fd 11
Looks like fine -- the framework actually asked for the ldap/... ticket on behalf of AD user, so S4U2Proxy did work. Can you see anything in LDAP server access logs at the same time?
Alexander,
Enable debugging for IPA server framework by creating a file /etc/ipa/server.conf with the following content:
[global] debug=True
Restart httpd and try again. Then collect logs and show that access attempt. The logs you attached so far only contain Apache modules' debugging information, not IPA framework's one.
Thanks for your reply. I went ahead and disabled the debug logs via httpd/conf.d/nss.conf to "warn", and now am only using server.conf "debug=True" (which was already set). I've attached the logs generated via a fresh request and `tail -f krb5kdc.log httpd/{access,error}_log dirsrv/slapd-IPA-DOMAIN-COM/{access,error}`, but you'll see that there is much less output.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6 for that. Web UI / CLI administration with AD users is only available in RHEL 8.0 beta.
Right. I did see a post suggesting limited AD user access in terms of Web UI and cli, but the post below suggests that ipa cli access was/is available as of FreeIPA 4.5.0:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Looks like fine -- the framework actually asked for the ldap/... ticket on behalf of AD user, so S4U2Proxy did work. Can you see anything in LDAP server access logs at the same time?
Thanks for the suggestion. There is a "SASL(-14) authorization failure" in the dirsrv/INSTANCE/access log, but no entries within the dirsv/INSTANCE/error log; I've attached a copy of the relevant log entries.
John DeSantis
Il giorno lun 8 apr 2019 alle ore 14:46 Alexander Bokovoy abokovoy@redhat.com ha scritto:
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
Hello all,
I'm wondering if anyone could help shed light on why IPA CLI commands fail for a trusted AD user, and why Web UI logins for the same user fail with the message "Your session has expired. Please re-login.", despite creating a view for the user via `ipa idoverrideuser-add 'Default Trust View' ad_user@ad_domain.com`. The symptoms appear almost identical to the post [0], except that the cli and Web UI were never working previously.
Enable debugging for IPA server framework by creating a file /etc/ipa/server.conf with the following content:
[global] debug=True
Restart httpd and try again. Then collect logs and show that access attempt. The logs you attached so far only contain Apache modules' debugging information, not IPA framework's one.
I am able to login via SSH (on a host with an HBAC configured), and able to `kinit` and obtain the appropriate tickets across the realms. I've configured the system accordingly, per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup.
I am running FreeIPA version 4.6.4 with a successful AD Trust (one way) using the range type "ipa-ad-trust-posix", both nodes completely re-provisioned (fresh installation purposes). SELinux is disabled, and the configuration IPA-wise is untouched, with the exception of enabling debugging and editing krb5.conf per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5...
I've attached Apache logs referencing the Web UI and from the console. From what I have found online, it should be possible to allow an AD user to login to Web UI and ipa CLI commands should function, too. All IPA services are running and have been restarted, just in case something was "stuck". The interesting entries within the logs: (Failed to unseal session data!, GSSapiImpersonate not On) seem to be red herrings.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6 for that. Web UI / CLI administration with AD users is only available in RHEL 8.0 beta.
# /var/log/krb5kdc.log
Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): closing down fd 11 Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): closing down fd 11
Looks like fine -- the framework actually asked for the ldap/... ticket on behalf of AD user, so S4U2Proxy did work. Can you see anything in LDAP server access logs at the same time?
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
Alexander,
Enable debugging for IPA server framework by creating a file /etc/ipa/server.conf with the following content:
[global] debug=True
Restart httpd and try again. Then collect logs and show that access attempt. The logs you attached so far only contain Apache modules' debugging information, not IPA framework's one.
Thanks for your reply. I went ahead and disabled the debug logs via httpd/conf.d/nss.conf to "warn", and now am only using server.conf "debug=True" (which was already set). I've attached the logs generated via a fresh request and `tail -f krb5kdc.log httpd/{access,error}_log dirsrv/slapd-IPA-DOMAIN-COM/{access,error}`, but you'll see that there is much less output.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6 for that. Web UI / CLI administration with AD users is only available in RHEL 8.0 beta.
Right. I did see a post suggesting limited AD user access in terms of Web UI and cli, but the post below suggests that ipa cli access was/is available as of FreeIPA 4.5.0:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Right, but it has the same limits, namely, since ID Override for AD user is not a part of any group in LDAP that can be used to grant access controls, all you can do with such access is what self-service ACI allows. E.g. you can add your own public ssh keys to ID Override entry you are associated with and change other parameters of the same entry.
RHEL 8 beta adds ability to associate ID Overrides with a group so that LDAP server sees this as a membership and applies ACIs correspondingly.
Looks like fine -- the framework actually asked for the ldap/... ticket on behalf of AD user, so S4U2Proxy did work. Can you see anything in LDAP server access logs at the same time?
Thanks for the suggestion. There is a "SASL(-14) authorization failure" in the dirsrv/INSTANCE/access log, but no entries within the dirsv/INSTANCE/error log; I've attached a copy of the relevant log entries.
This looks like the actual problem here.
The only place where LDAP server returns SASL_NOAUTHZ is
/* map the sasl username into an entry */ entry = ids_sasl_user_to_entry(conn, context, user, user_realm); if (entry == NULL) { /* Specific return value is supposed to be set instead of an generic error (SASL_FAIL) for Cyrus SASL */ returnvalue = SASL_NOAUTHZ; goto fail; }
This means it was unable to map the incoming Kerberos principal from the SASL GSSAPI (or GSS-SPNEGO) to the LDAP entry. Can you check if /usr/share/ipa/updates/71-idviews-sasl-mapping.update is applied at this server?
You can apply it with
ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update
John DeSantis
Il giorno lun 8 apr 2019 alle ore 14:46 Alexander Bokovoy abokovoy@redhat.com ha scritto:
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
Hello all,
I'm wondering if anyone could help shed light on why IPA CLI commands fail for a trusted AD user, and why Web UI logins for the same user fail with the message "Your session has expired. Please re-login.", despite creating a view for the user via `ipa idoverrideuser-add 'Default Trust View' ad_user@ad_domain.com`. The symptoms appear almost identical to the post [0], except that the cli and Web UI were never working previously.
Enable debugging for IPA server framework by creating a file /etc/ipa/server.conf with the following content:
[global] debug=True
Restart httpd and try again. Then collect logs and show that access attempt. The logs you attached so far only contain Apache modules' debugging information, not IPA framework's one.
I am able to login via SSH (on a host with an HBAC configured), and able to `kinit` and obtain the appropriate tickets across the realms. I've configured the system accordingly, per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup.
I am running FreeIPA version 4.6.4 with a successful AD Trust (one way) using the range type "ipa-ad-trust-posix", both nodes completely re-provisioned (fresh installation purposes). SELinux is disabled, and the configuration IPA-wise is untouched, with the exception of enabling debugging and editing krb5.conf per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5...
I've attached Apache logs referencing the Web UI and from the console. From what I have found online, it should be possible to allow an AD user to login to Web UI and ipa CLI commands should function, too. All IPA services are running and have been restarted, just in case something was "stuck". The interesting entries within the logs: (Failed to unseal session data!, GSSapiImpersonate not On) seem to be red herrings.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6 for that. Web UI / CLI administration with AD users is only available in RHEL 8.0 beta.
# /var/log/krb5kdc.log
Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): closing down fd 11 Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): closing down fd 11
Looks like fine -- the framework actually asked for the ldap/... ticket on behalf of AD user, so S4U2Proxy did work. Can you see anything in LDAP server access logs at the same time?
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
Alexander,
This means it was unable to map the incoming Kerberos principal from the SASL GSSAPI (or GSS-SPNEGO) to the LDAP entry. Can you check if /usr/share/ipa/updates/71-idviews-sasl-mapping.update is applied at this server?
You can apply it with
ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update
It showed up in the configuration, but just to test I went ahead and ran it to be 100% sure, and the output stated nothing was modified and reported a successful exit:
# ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update Update complete, no data were modified The ipa-ldap-updater command was successful
Any other ideas?
Thank you! John DeSantis
Il giorno mar 9 apr 2019 alle ore 02:48 Alexander Bokovoy abokovoy@redhat.com ha scritto:
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
Alexander,
Enable debugging for IPA server framework by creating a file /etc/ipa/server.conf with the following content:
[global] debug=True
Restart httpd and try again. Then collect logs and show that access attempt. The logs you attached so far only contain Apache modules' debugging information, not IPA framework's one.
Thanks for your reply. I went ahead and disabled the debug logs via httpd/conf.d/nss.conf to "warn", and now am only using server.conf "debug=True" (which was already set). I've attached the logs generated via a fresh request and `tail -f krb5kdc.log httpd/{access,error}_log dirsrv/slapd-IPA-DOMAIN-COM/{access,error}`, but you'll see that there is much less output.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6 for that. Web UI / CLI administration with AD users is only available in RHEL 8.0 beta.
Right. I did see a post suggesting limited AD user access in terms of Web UI and cli, but the post below suggests that ipa cli access was/is available as of FreeIPA 4.5.0:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Right, but it has the same limits, namely, since ID Override for AD user is not a part of any group in LDAP that can be used to grant access controls, all you can do with such access is what self-service ACI allows. E.g. you can add your own public ssh keys to ID Override entry you are associated with and change other parameters of the same entry.
RHEL 8 beta adds ability to associate ID Overrides with a group so that LDAP server sees this as a membership and applies ACIs correspondingly.
Looks like fine -- the framework actually asked for the ldap/... ticket on behalf of AD user, so S4U2Proxy did work. Can you see anything in LDAP server access logs at the same time?
Thanks for the suggestion. There is a "SASL(-14) authorization failure" in the dirsrv/INSTANCE/access log, but no entries within the dirsv/INSTANCE/error log; I've attached a copy of the relevant log entries.
This looks like the actual problem here.
The only place where LDAP server returns SASL_NOAUTHZ is
/* map the sasl username into an entry */ entry = ids_sasl_user_to_entry(conn, context, user, user_realm); if (entry == NULL) { /* Specific return value is supposed to be set instead of an generic error (SASL_FAIL) for Cyrus SASL */ returnvalue = SASL_NOAUTHZ; goto fail; }
This means it was unable to map the incoming Kerberos principal from the SASL GSSAPI (or GSS-SPNEGO) to the LDAP entry. Can you check if /usr/share/ipa/updates/71-idviews-sasl-mapping.update is applied at this server?
You can apply it with
ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update
John DeSantis
Il giorno lun 8 apr 2019 alle ore 14:46 Alexander Bokovoy abokovoy@redhat.com ha scritto:
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
Hello all,
I'm wondering if anyone could help shed light on why IPA CLI commands fail for a trusted AD user, and why Web UI logins for the same user fail with the message "Your session has expired. Please re-login.", despite creating a view for the user via `ipa idoverrideuser-add 'Default Trust View' ad_user@ad_domain.com`. The symptoms appear almost identical to the post [0], except that the cli and Web UI were never working previously.
Enable debugging for IPA server framework by creating a file /etc/ipa/server.conf with the following content:
[global] debug=True
Restart httpd and try again. Then collect logs and show that access attempt. The logs you attached so far only contain Apache modules' debugging information, not IPA framework's one.
I am able to login via SSH (on a host with an HBAC configured), and able to `kinit` and obtain the appropriate tickets across the realms. I've configured the system accordingly, per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup.
I am running FreeIPA version 4.6.4 with a successful AD Trust (one way) using the range type "ipa-ad-trust-posix", both nodes completely re-provisioned (fresh installation purposes). SELinux is disabled, and the configuration IPA-wise is untouched, with the exception of enabling debugging and editing krb5.conf per the URL: https://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5...
I've attached Apache logs referencing the Web UI and from the console. From what I have found online, it should be possible to allow an AD user to login to Web UI and ipa CLI commands should function, too. All IPA services are running and have been restarted, just in case something was "stuck". The interesting entries within the logs: (Failed to unseal session data!, GSSapiImpersonate not On) seem to be red herrings.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6 for that. Web UI / CLI administration with AD users is only available in RHEL 8.0 beta.
# /var/log/krb5kdc.log
Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): closing down fd 11 Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 131.247.188.132: ISSUE: authtime 1554738690, etypes {rep=18 tkt=18 ses=18}, HTTP/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM for ldap/IPASERVER1.ipa.domain.com@IPA.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): ... CONSTRAINED-DELEGATION s4u-client=desantis@AD.DOMAIN.COM Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): closing down fd 11
Looks like fine -- the framework actually asked for the ldap/... ticket on behalf of AD user, so S4U2Proxy did work. Can you see anything in LDAP server access logs at the same time?
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
freeipa-users@lists.fedorahosted.org