11:01 a.m.
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(a)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.fedorahosted.org/message/5OWV3YTPG4ZETKJG2GVP2LDDTUUIAC2D/
> 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(a)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(a)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.conf
> >> >
> >> >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(a)IPA.DOMAIN.COM for
ldap/IPASERVER1.ipa.domain.com(a)IPA.DOMAIN.COM
> >> >Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): ...
CONSTRAINED-DELEGATION s4u-client=desantis(a)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(a)IPA.DOMAIN.COM for
ldap/IPASERVER1.ipa.domain.com(a)IPA.DOMAIN.COM
> >> >Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): ...
CONSTRAINED-DELEGATION s4u-client=desantis(a)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