AD Trust and ipa cli/Web UI

[John Desantis]

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.

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.2Fk...

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/[e-mail]...

[Alexander Bokovoy]

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.2Fk...
>
> 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

[John Desantis]

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/[e-mail]...

>  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(a)redhat.com&gt; 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]

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/[e-mail]...
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&gt; 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

[John Desantis]

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&gt; 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/[e-mail]/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
> &gt;&lt;abokovoy(a)redhat.com&gt; 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