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
<aboko...@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.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....@ipa.domain.com for 
ldap/ipaserver1.ipa.domain....@ipa.domain.com
>Apr 08 12:01:30 IPASERVER1.ipa.domain.com krb5kdc[10297](info): ... 
CONSTRAINED-DELEGATION s4u-client=desan...@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....@ipa.domain.com for 
ldap/ipaserver1.ipa.domain....@ipa.domain.com
>Apr 08 12:01:31 IPASERVER1.ipa.domain.com krb5kdc[10298](info): ... 
CONSTRAINED-DELEGATION s4u-client=desan...@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 mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org

Reply via email to