On ti, 06 joulu 2016, TomK wrote:
On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:
On su, 04 joulu 2016, TomK wrote:
Could not get much from logs and decided to start fresh. When I run
this:
ipa trust-add --type=ad mds.xyz --admin Administrator --password
Trust works fine and id t...@mds.xyz returns a valid result.
However when I run the following on both masters on a fresh new setup:
ipa-adtrust-install --netbios-name=NIX -a "<SECRET>"
ipa trust-add --type=ad "mds.xyz" --trust-secret
and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work. I didn't get anything
by typing id t...@mds.xyz. (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above. )
The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.
And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).
Nothing I tried in AD Trust creation allowed me to make one with type
Forest. Just realm. I recall I had a trust type of Forest but in
trying various options I lost how I did that. Or perhaps I hadn't
payed attention and it got created indirectly as part of another
action I took. The domain functional level I'm using is Windows
Server 2008. Using a lower value for testing.
This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.
Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.
My IPA version is 4.2 right now. It came with the CentOS 7.2.
Looking forward to 4.4. Not sure when you plan to include it as part
of the latest CentOS base. Indeed some ports were not open (445).
I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:
for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp
53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp
53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd
--zone=public --permanent --add-port=$KEY; done
[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
interfaces:
sources:
services: dhcpv6-client ntp ssh
ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp
135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp
139/udp 138/udp 53/udp 636/tcp
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
[root@idmipa01 ~]#
On Windows Side (The nslookup results were the same before the
firewall change however.):
Firewall changes cannot affect DNS as you already had DNS port open.
On the AD side, I added the SRV records for the second AD DC,
manually, since earlier there were no results printed on the AD DC
command line for the second AD DC, when I typed the command
_ldap._tcp.mds.xyz.
One additional question I had with the setup is in regards to the
failover. I see the ipa_server entry in /etc/sssd/sssd.conf pointing
to two of the master IPA nodes. Where can I find the additional
settings that control priority of the listed server or order they are
checked?
You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.
What I ran to get the above is:
1) ipa-client-install --force-join -p admin -w "<HUSH!>"
--fixed-primary --server=idmipa01.nix.mds.xyz
--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ
-U
2) realm join mds.xyz
This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).
Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.
You can send the trace to me off-list.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
