On Tue, Jul 25, 2017 at 10:12:38AM -0400, Jason Hensley via FreeIPA-users wrote:
On Tue, Jul 25, 2017 at 2:29 AM, Jakub Hrozek via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
> On Mon, Jul 24, 2017 at 04:25:14PM -0400, Jason Beck via FreeIPA-users
> wrote:
> > On Mon, Jul 24, 2017 at 2:53 PM, Jason Beck <jason.s.beck(a)gmail.com>
> wrote:
> >
> > > On Mon, Jul 24, 2017 at 2:23 PM, Jakub Hrozek <jhrozek(a)redhat.com>
> wrote:
> > >
> > >> On Mon, Jul 24, 2017 at 01:53:20PM -0400, Jason Beck wrote:
> > >> > On Mon, Jul 24, 2017 at 9:25 AM, Jakub Hrozek
<jhrozek(a)redhat.com>
> > >> wrote:
> > >> >
> > >> > > On Mon, Jul 24, 2017 at 09:05:59AM -0400, Jason Beck wrote:
> > >> > > > On Jul 24, 2017 4:14 AM, "Jakub Hrozek via
FreeIPA-users" <
> > >> > > > freeipa-users(a)lists.fedorahosted.org> wrote:
> > >> > > >
> > >> > > > > On Fri, Jul 21, 2017 at 03:43:58PM -0400, Jason
Beck via
> > >> FreeIPA-users
> > >> > > > > wrote:
> > >> > > > > > I have been trying to reliably get an AD
trust setup for a
> few
> > >> weeks
> > >> > > and
> > >> > > > > no
> > >> > > > > > matter what I try, when I goto add AD users
to an external
> > >> group in
> > >> > > > > > FreeIPA, I get:
> > >> > > > > >
> > >> > > > > > "trusted domain object not found"
> > >> > > > > >
> > >> > > > > > Googling around tends to always yield the
same suggestions:
> > >> > > > > >
> > >> > > > > > 1) Check time sync
> > >> > > > > > 2) Check DNS
> > >> > > > > > 3) Check firewall
> > >> > > > > >
> > >> > > > > > I have done all of this ad nauseam in several
different
> > >> environments
> > >> > > with
> > >> > > > > > several different versions of FreeIPA and
Windows servers.
> I
> > >> have
> > >> > > > > gotten a
> > >> > > > > > setup to work maybe 2% of the time out of
hundreds of
> attempts.
> > >> > > > > >
> > >> > > > > > I am currently using FreeIPA 4.5.2 on Fedora
25 (out of the
> COPR
> > >> > > repo).
> > >> > > > > I
> > >> > > > > > am trying to establish trust with a mixed
Windows 2012 &
> 2008
> > >> > > forest. I
> > >> > > > > > have tried both one and two way trusts.
Everything seems to
> > >> work
> > >> > > fine up
> > >> > > > > > until I try to add AD users to FreeIPA.
> > >> > > > > >
> > >> > > > > > I have verified all of the requisite DNS
records exist and
> > >> return the
> > >> > > > > > proper information on both sides, there are
no firewalls
> > >> between any
> > >> > > of
> > >> > > > > the
> > >> > > > > > hosts, and the AD servers and FreeIPA servers
are
> synchronized
> > >> by the
> > >> > > > > same
> > >> > > > > > NTP servers.
> > >> > > > > >
> > >> > > > > > What could I possibly be missing?
> > >> > > > >
> > >> > > > > Can you resolve the object you're trying to
add with sssd?
> > >> > > > >
> > >> > > > > e.g. id foo(a)windows.domain
> > >> > > > > _______________________________________________
> > >> > > > > FreeIPA-users mailing list --
freeipa-users(a)lists.fedorahost
> > >>
ed.org
> > >> > > > > To unsubscribe send an email to
freeipa-users-leave@lists.
> > >> > >
fedorahosted.org
> > >> > > >
> > >> > > >
> > >> > > > No. I can login via Kerberos, kinit user(a)ad.domain.
But
> neither
> > >> id
> > >> > > > user(a)ad.domain nor getent passwd user(a)ad.domain are
successful.
> > >> > >
> > >> > > Then please follow
> > >> > >
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
> > >> > >
> > >> >
> > >> > Jakub,
> > >> >
> > >> > Thank you for the support thus far. I have followed some
> suggestions
> > >> in
> > >> > the sssd troubleshooting link you provided. I am seeing these
> errors
> > >> > whenever I try to perform an operation that would lookup an AD
user,
> > >> e.g.
> > >> > id user(a)ad.domain. I am performing the user lookups on the
> primary IPA
> > >> > server itself.
> > >> >
> > >> > *sssd.conf:*
> > >> >
> > >> > [domain/ipa.domain]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > cache_credentials = True
> > >> >
> > >> > enumerate = False
> > >> >
> > >> > krb5_store_password_if_offline = True
> > >> >
> > >> > ipa_domain = ipa.domain
> > >> >
> > >> > id_provider = ipa
> > >> >
> > >> > auth_provider = ipa
> > >> >
> > >> > access_provider = ipa
> > >> >
> > >> > ipa_hostname = ipa01.ipa.domain
> > >> >
> > >> > chpass_provider = ipa
> > >> >
> > >> > ipa_server = _srv_
> > >> >
> > >> > ldap_tls_cacert = /etc/ipa/ca.crt
> > >> >
> > >> > [sssd]
> > >> >
> > >> > services = sudo, nss, ifp, pam, ssh, pac
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > domains = ipa.domain
> > >> >
> > >> > [nss]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > [pam]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > [sudo]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > [autofs]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > [ssh]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > [pac]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > [ifp]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> > [secrets]
> > >> >
> > >> > debug_level = 10
> > >> >
> > >> Are you sure it's the server itself? Because for one, I would
expect
> to
> > >> see ipa_server_mode=True in sssd.conf and also ipa_server set to fqdn
> of
> > >> 'self', not to _srv_.
> > >>
> > >> Also the s2n exop failed messages make it look like the debug
messages
> > >> are from a client.
> > >>
> > >> Anyway, one thing to examine is:
> > >> > Jul 24 13:20:04 ipa01.ipa.domain sssd[6535]: (Mon Jul 24
13:20:04
> 2017)
> > >> > [sssd[nss]] [cache_req_common_dp_recv] (0x0040): CR #49: Data
> Provider
> > >> > Error: 3, 5, Failed to get reply from Data Provider
> > >> >
> > >> > Jul 24 13:20:04 ipa01.ipa.domain sssd[6535]: (Mon Jul 24
13:20:04
> 2017)
> > >> > [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider
returned
> an
> > >> > error [org.freedesktop.sssd.Error.DataProvider.Offline]
> > >> >
> > >>
> > >> This indicates a communication issue towards the server. You should
> look
> > >> for messages that say that 'a port is not working'.
> > >>
> > >
> > > Sorry, I've been troubleshooting this for weeks, trying various
> settings.
> > > When I add the variables to sssd.conf
> > >
> > > [domain/ipa.domain]
> > > ...
> > > ipa_server_mode = True
> > > ipa_server = ipa01.ipa.domain
> > > ...
> > >
> > > and restart sssd:
> > >
> > > I am now getting the following errors, also id user(a)ad.domain and/or
> > > getent passwd user(a)ad.domain return failure immediately:
> > >
> > > Jul 24 14:40:41 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:40:41
> > > 2017) [sssd[be[ipa.domain]]] [sdap_get_server_opts_from_rootdse]
> > > (0x0020): ldap_rootdse_last_usn configured but not found in rootdse!
> > >
> > > Jul 24 14:40:41 iad1aipa01.ipa.domain sssd_be[12156]: GSSAPI client
> step 1
> > >
> > > Jul 24 14:40:41 iad1aipa01.ipa.domain sssd_be[12156]: GSSAPI client
> step 1
> > >
> > > Jul 24 14:40:41 iad1aipa01.ipa.domain sssd_be[12156]: GSSAPI client
> step 1
> > >
> > > Jul 24 14:40:41 iad1aipa01.ipa.domain sssd_be[12156]: GSSAPI client
> step 2
> > >
> > > Jul 24 14:40:47 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:40:47
> > > 2017) [sssd[be[ipa.domain]]] [ipa_sudo_fetch_rules_done] (0x0040):
> Received
> > > 0 sudo rules
> > >
> > > Jul 24 14:41:13 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:41:13
> > > 2017) [sssd[nss]] [cache_req_data_create] (0x0020): Bug: id cannot be
> 0!
> > >
> > > Jul 24 14:41:13 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:41:13
> > > 2017) [sssd[nss]] [cache_req_data_create] (0x0020): Unable to create
> > > cache_req data [1432158209]: Internal Error
> > >
> > > Jul 24 14:41:13 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:41:13
> > > 2017) [sssd[nss]] [nss_getby_id] (0x0020): Unable to set cache request
> data!
> > >
> > > Jul 24 14:41:27 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:41:27
> > > 2017) [sssd[pac]] [accept_fd_handler] (0x0020): Access denied for uid
> [389].
> > >
> > > Jul 24 14:42:13 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:42:13
> > > 2017) [sssd[nss]] [cache_req_data_create] (0x0020): Bug: id cannot be
> 0!
> > >
> > > Jul 24 14:42:13 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:42:13
> > > 2017) [sssd[nss]] [cache_req_data_create] (0x0020): Unable to create
> > > cache_req data [1432158209]: Internal Error
> > >
> > > Jul 24 14:42:13 iad1aipa01.ipa.domain sssd[12154]: (Mon Jul 24 14:42:13
> > > 2017) [sssd[nss]] [nss_getby_id] (0x0020): Unable to set cache request
> data!
> > >
> > >
> > > As far as ports not working, all of the IPA services are running, the
> > > local firewalls are all turned off on the IPA servers and the firewalls
> > > between the AD servers and the IPA servers are completely open for the
> IPA
> > > server addresses. LDAP queries work fine to both the AD servers and
> the
> > > IPA servers. I can kinit fine as an AD user on the IPA servers.
> > >
> > > # ipactl status
> > >
> > > Directory Service: RUNNING
> > >
> > > krb5kdc Service: RUNNING
> > >
> > > kadmin Service: RUNNING
> > >
> > > named Service: RUNNING
> > >
> > > httpd Service: RUNNING
> > >
> > > ipa-custodia Service: RUNNING
> > >
> > > pki-tomcatd Service: RUNNING
> > >
> > > smb Service: RUNNING
> > >
> > > winbind Service: RUNNING
> > >
> > > ipa-otpd Service: RUNNING
> > >
> > > ipa-dnskeysyncd Service: RUNNING
> > >
> > > ipa: INFO: The ipactl command was successful
> > >
> > I have reinstalled everything from scratch again and run through the
> setup
> > instructions here:
https://www.freeipa.org/page/
> Active_Directory_trust_setup
> > .
> >
> > Everything "works" until I get to the point of adding an external
user to
> > an external group in FreeIPA.
> >
> > The only configuration I have changed is to increase the debug logging in
> > both sssd.conf and smb/netconf and adding the 'auth_to_local' lines in
> > krb5.conf.
> >
> > When I start sssd I am seeing the following:
> >
> > Jul 24 16:10:14 ipa01.ipa.domain sssd[be[ipa.domain]][11828]: SRV
> discovery
> > is enabled on the IPA server while using custom dns_discovery_domain. DNS
> > discovery of trusted AD domain will likely fail. It is recommended not to
> > use SRV discovery or the dns_discovery_domain option for the IPA domain
> > while running on the server itself
> >
> > Jul 24 16:10:14 ipa01.ipa.domain sssd[11826]: (Mon Jul 24 16:10:14 2017)
> > [sssd[be[ipa.chewy.com]]] [ipa_init_server_mode] (0x0020): SRV
> discovery is
> > enabled on the IPA server while using custom dns_discovery_domain. DNS
> > discovery of trusted AD domain will likely fail. It is recommended not to
> > use SRV discovery or the dns_discovery_domain option for the IPA domain
> > while running on the server itself
> >
> >
> > I am not setting a custom dns_discovery_domain in sssd.conf.
>
> Maybe the debug message is imprecise, IIRC this also gets logged if the
> setup sees a "_srv_" in the list of ipa_server values.
>
> >
> > Whenever I try to id user(a)ad.domain or getent passwd user(a)ad.domain
> nothing
> > is logged in sssd. Is it possible to have the sssd on the IPA servers
> also
> > be clients?
>
> No, the sssd on the servers is really running in a special
> configuration.
>
> How exactly did you end up with that configuration? Did you run anything
> else except ipa-server-install and ipa-adtrust-install on the server?
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>
I just followed the steps outlined here:
https://www.freeipa.org/page/
Active_Directory_trust_setup
to be fair this was on a host that had previously has freeipa configured
and uninstalled via ipa-server-install --uninstall so I am unsure if there
may have been artifacts left over from that.
This is with FreeIPA 4.5.2 and deps from the COPR repo on Fedora 25.
But I'm really at loss to explain why your /IDM master/ would end up
with "ipa_server = _srv_" and no "ipa_server_mode = True" in
sssd.conf.
If you can reproduce that after running ipa-server-install, then I would
say that is a bug in the IPA installer (although I would hope bugs like
this would be discovered sooner). If you can reproduce this, I would
file a bug and attach /var/log/ipaserver-install.log.(see