[Freeipa-users] Mapping users from AD to IPA KDC

List dedicated to discussions about use, configuration and deployment of the IPA server. freeipa-users at redhat.com
Wed Dec 7 04:32:30 UTC 2016


On 12/6/2016 3:37 PM, Alexander Bokovoy wrote:
> 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 tom at 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 tom at 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 at 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 at 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.
>
>
>

Ok, let me take these away and get back to you.  ( On realm, thank you. 
Hadn't reviewed the changes it did fully before logging off. )

-- 
Cheers,
Tom K.
-------------------------------------------------------------------------------------

Living on earth is expensive, but it includes a free trip around the sun.




More information about the Freeipa-users mailing list