On 6/1/18, 12:20 PM, "Merritt, Todd R - (tmerritt) via FreeIPA-users"
On 5/31/18, 11:32 AM, "Alexander Bokovoy" <abokovoy(a)redhat.com>
On to, 31 touko 2018, Merritt, Todd R - (tmerritt) wrote:
On 5/30/18, 10:59 PM, "Alexander Bokovoy" <abokovoy(a)redhat.com> wrote:
On ke, 30 touko 2018, Merritt, Todd R - (tmerritt) wrote:
>On 5/29/18, 7:59 PM, "Alexander Bokovoy" <abokovoy(a)redhat.com>
> On ti, 29 touko 2018, Merritt, Todd R - (tmerritt) via FreeIPA-users wrote:
> > I'm trying to establish a two way trust with an AD
> > domain and seem to be running into some issues. I am
> > able to establish a one way trust following the guide
> > at
> > without any issues. When I destroy that trust and try
> > to establish a new one with two-way specified to the
> > same AD domain it throws what I believe to be a
> > misleading error message and the trust is not
> > established.
> How did you destroy that trust?
> >[root(a)IPA.DOMAIN /]# ipa trust-add --type=ad AD_DOMAIN --admin
AD_ADMIN_USER --password --two-way=true
> >Active Directory domain administrator's password:
> >ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most
likely it is a DNS or firewall issue
> >I've checked that both the AD DC and the free IPA hosts can resolve
> >service entries and verified that there are no firewall blocks in place
> >between these two hosts. I believe the issue is an LDAP permission
> >issue of some sort based on the following log snippet
> Add 'log level = 100' to /usr/share/ipa/smb.conf.empty and re-try
> 'ipa trust-add'. You'll get additional debug information in
> error_log. Provide that one off-list.
>Thanks, I removed it with trust-del
>[root(a)IPA.DOMAIN /]# ipa trust-del AD_DOMAIN
>Deleted trust "AD_DOMAIN"
>I'll send you a copy of the http error log directly.
Thanks. Looking at the error_log, I see two issues:
Validation of trust failed because AD DCs were unable to reach to IPA
DCs. This typically means AD DCs unable to discover IPA DCs over DNS SRV
records -- they look up using standard Active Directory discovery means,
e.g. trying to find out SRV record for
Can you show output of 'ipa dns-update-system-records --dry-run'?
netr_LogonControl2Ex: struct netr_LogonControl2Ex
out: struct netr_LogonControl2Ex
query : *
query : union netr_CONTROL_QUERY_INFORMATION(case
info2 : *
info2: struct netr_NETLOGON_INFO_2
flags : 0x00000080 (128)
pdc_connection_status : WERR_NO_LOGON_SERVERS
trusted_dc_name : *
trusted_dc_name : ''
tc_connection_status : WERR_NO_LOGON_SERVERS
result : WERR_OK
[root@IPA /]# rpm -q ipa-server
[root@IPA /]# ipa dns-update-system-records --dry-run
ipa: ERROR: unknown command 'dns-update-system-records'
Ok, 4.2 doesn't have that command.
On my single master setup it looks like this:
# ipa dns-update-system-records --dry-run | sed -e
IPA DNS records:
_kerberos-master._tcp.IPA_DOMAIN. 86400 IN SRV 0 100 88
_kerberos-master._udp.IPA_DOMAIN. 86400 IN SRV 0 100 88
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.IPA_DOMAIN. 86400 IN
SRV 0 100 88 ipa-server.IPA_DOMAIN.
_kerberos._tcp.dc._msdcs.IPA_DOMAIN. 86400 IN SRV 0 100 88
_kerberos._tcp.IPA_DOMAIN. 86400 IN SRV 0 100 88 ipa-server.IPA_DOMAIN.
_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.IPA_DOMAIN. 86400 IN
SRV 0 100 88 ipa-server.IPA_DOMAIN.
_kerberos._udp.dc._msdcs.IPA_DOMAIN. 86400 IN SRV 0 100 88
_kerberos._udp.IPA_DOMAIN. 86400 IN SRV 0 100 88 ipa-server.IPA_DOMAIN.
_kerberos.IPA_DOMAIN. 86400 IN TXT "IPA_DOMAIN"
_kpasswd._tcp.IPA_DOMAIN. 86400 IN SRV 0 100 464 ipa-server.IPA_DOMAIN.
_kpasswd._udp.IPA_DOMAIN. 86400 IN SRV 0 100 464 ipa-server.IPA_DOMAIN.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.IPA_DOMAIN. 86400 IN SRV 0
100 389 ipa-server.IPA_DOMAIN.
_ldap._tcp.dc._msdcs.IPA_DOMAIN. 86400 IN SRV 0 100 389
_ldap._tcp.IPA_DOMAIN. 86400 IN SRV 0 100 389 ipa-server.IPA_DOMAIN.
ipa-ca.IPA_DOMAIN. 86400 IN A some-ipv4-address
ipa-ca.IPA_DOMAIN. 86400 IN AAAA some-ipv6-address
You need entries that exist in _mscds.IPA_DOMAIN, these are the ones
searched by AD DCs.
If I try to manually lookup that domain I get an NXDOMAIN
[root@IPA /]# nslookup -type=srv
** server can't find ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.IPA_DOMAIN:
The DNS entries were actually correct, I had a missing _ in my test query but thank
you for pointing me in the right direction. The underlying issues ended up being a mix of
firewall permits on the windows side and a number of missing port bindings to my docker
container where ipa was running for 135/tcp and 1024-1300/tcp. After correcting those
issues I was able to establish the trust.
Well, I _thought_ I had the trust established. I tried to run kvno -S cifs
but I get an error that the server is not found in the Kerberos database. I tried to
subsequently run "ipa trust-fetch-domains AD_DOMAIN" and got an error that the
time may not be in sync between the ipa and ad dc but I verified that the is synced
between them. I have a copy of the error log from the IPA server from trying to run
trust-fetch-domains if that's helpful.