On Tue, Jul 25, 2017 at 2:29 AM, Jakub Hrozek via FreeIPA-users < freeipa-users@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.b...@gmail.com> > wrote: > > > > > On Mon, Jul 24, 2017 at 2:23 PM, Jakub Hrozek <jhro...@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 <jhro...@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@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@windows.domain > > >> > > > > _______________________________________________ > > >> > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahost > > >> ed.org > > >> > > > > To unsubscribe send an email to freeipa-users-leave@lists. > > >> > > fedorahosted.org > > >> > > > > > >> > > > > > >> > > > No. I can login via Kerberos, kinit user@ad.domain. But > neither > > >> id > > >> > > > user@ad.domain nor getent passwd user@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@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@ad.domain and/or > > > getent passwd user@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@ad.domain or getent passwd user@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@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@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.
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
