[Freeipa-devel] Freeipa-devel Digest, Vol 113, Issue 35
Alexander Bokovoy
abokovoy at redhat.com
Mon Oct 10 08:21:44 UTC 2016
On ma, 10 loka 2016, rajat gupta wrote:
>Hi,
>
>https://access.redhat.com/documentation/en-US/Red_Hat_
>Enterprise_Linux/7/html/Windows_Integration_Guide/
>trust-requirements.html#trust-req-ports
>
>these port are required for trust. Is port 88 required to open from ipa
>client to AD?
Yes. Port 88 tcp/udp.
Authentication is always done by the authoritative source. In case of AD
users, an authoritative source would be AD DCs of the corresponding AD
domain.
If you login with GSSAPI Kerberos as AD user, then your client software would
present a Kerberos ticket to some IPA service that it obtained from IPA
KDC by way of presenting a cross-realm TGT which was obtained from own
AD DCs. SSSD on IPA side would still do validation of the ticket.
If you login with password as AD user, SSSD would obtain initial
Kerberos ticket (TGT) by authenticating as AD user with that password.
It would try to do 'kinit'-like procedure against its own IPA KDC. IPA
KDC will return a client-side referral which points to AD realm of that
AD user and Kerberos library on IPA client will perform referral
chasing to find out an AD DC.
Thus, IPA clients need to know about AD domains and have Kerberos access
to them.
If you want to support password change from IPA client side for AD
users, you also need to allow Kerberos kpasswd protocol support (port
464 tcp/udp).
With FreeIPA 4.2 or later we support KDC proxy over HTTPS (MS-KKDCP)
protocol. Technically this means you can force all IPA clients to always
talk to IPA masters with Kerberos and then IPA masters would rely
Kerberos requests to AD DCs. This is useful in DMZ scenarios. However,
password change cannot be proxied this way.
>
>On Mon, Oct 10, 2016 at 9:21 AM, <freeipa-devel-request at redhat.com> wrote:
>
>> Send Freeipa-devel mailing list submissions to
>> freeipa-devel at redhat.com
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>> or, via email, send a message with subject or body 'help' to
>> freeipa-devel-request at redhat.com
>>
>> You can reach the person managing the list at
>> freeipa-devel-owner at redhat.com
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Freeipa-devel digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: [PATCH 0497] Py3: fix unicode/str error in
>> LDAP*ReverseMember (Jan Cholasta)
>> 2. [freeipa PR#134][comment] DNS URI support (pspacek)
>> 3. [freeipa PR#10][comment] Client-side CSR autogeneration (jcholast)
>> 4. Re: [PATCH 0058] Make get_entries not ignore its size_limit
>> argument (Standa Laznicka)
>> 5. Re: kinit: Cannot contact any KDC for realm... from Freeipa
>> clinet (Active Directory trust setup) (Petr Spacek)
>> 6. [freeipa PR#146][opened] WebUI: fix API Browser menu label
>> (pvomacka)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 10 Oct 2016 07:57:13 +0200
>> From: Jan Cholasta <jcholast at redhat.com>
>> To: Martin Basti <mbasti at redhat.com>, freeipa-devel
>> <freeipa-devel at redhat.com>
>> Subject: Re: [Freeipa-devel] [PATCH 0497] Py3: fix unicode/str error
>> in LDAP*ReverseMember
>> Message-ID: <ac85aef1-231b-d5a2-37c0-44c7250e5a39 at redhat.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> On 7.6.2016 10:35, Martin Basti wrote:
>> >
>> >
>> > On 07.06.2016 10:35, Jan Cholasta wrote:
>> >> On 7.6.2016 10:29, Martin Basti wrote:
>> >>>
>> >>>
>> >>> On 07.06.2016 09:08, Jan Cholasta wrote:
>> >>>> On 6.6.2016 14:33, Martin Basti wrote:
>> >>>>> https://fedorahosted.org/freeipa/ticket/5923
>> >>>>>
>> >>>>> Patch attached.
>> >>>>
>> >>>> Could we drop the error message parsing and do something sane instead?
>> >>>>
>> >>>
>> >>> Not now, we can do it later and push this patch just as workaround
>> >>
>> >> What's the point of that?
>> >>
>> > Point is that it will work as before, and I don't have to time to fix it
>> > nicely now.
>>
>> Bump. Do you now have time to fix it nicely, or should we move the
>> ticket to 4.5 or later?
>>
>> --
>> Jan Cholasta
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 10 Oct 2016 08:03:00 +0200
>> From: pspacek <freeipa-github-notification at redhat.com>
>> To: freeipa-devel at redhat.com
>> Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support
>> Message-ID:
>> <gh-freeipa/freeipa-134-2016-7bd42aa5-c029-4a55-b592-
>> ca678c7dbe20 at freeipa-github-notification.redhat.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> URL: https://github.com/freeipa/freeipa/pull/134
>> Title: #134: DNS URI support
>>
>> pspacek commented:
>> """
>> I thought that messing with API numbers in VERSION is not be necessary
>> anymore after we introduced thin client. @jcholast ?
>> """
>>
>> See the full comment at https://github.com/freeipa/
>> freeipa/pull/134#issuecomment-252542215
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 10 Oct 2016 08:32:19 +0200
>> From: jcholast <freeipa-github-notification at redhat.com>
>> To: freeipa-devel at redhat.com
>> Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR
>> autogeneration
>> Message-ID:
>> <gh-freeipa/freeipa-10-2016-5d58c6bf-18d9-472a-a788-
>> 8b40194d7acc at freeipa-github-notification.redhat.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> URL: https://github.com/freeipa/freeipa/pull/10
>> Title: #10: Client-side CSR autogeneration
>>
>> jcholast commented:
>> """
>> @LiptonB, I have added some inline comments.
>>
>> Also, have you seen [my latest reply in the design thread](
>> https://www.redhat.com/archives/freeipa-devel/2016-September/msg00082.html
>> )?
>> """
>>
>> See the full comment at https://github.com/freeipa/
>> freeipa/pull/10#issuecomment-252544625
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Mon, 10 Oct 2016 08:47:50 +0200
>> From: Standa Laznicka <slaznick at redhat.com>
>> To: Jan Cholasta <jcholast at redhat.com>, freeipa-devel
>> <freeipa-devel at redhat.com>
>> Subject: Re: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore
>> its size_limit argument
>> Message-ID: <c552597b-df9f-0ce0-34b5-44b9c3c9d334 at redhat.com>
>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>
>> On 10/10/2016 07:53 AM, Jan Cholasta wrote:
>> > On 7.10.2016 12:23, Standa Laznicka wrote:
>> >> On 10/07/2016 08:31 AM, Jan Cholasta wrote:
>> >>> On 17.8.2016 13:47, Stanislav Laznicka wrote:
>> >>>> On 08/11/2016 02:59 PM, Stanislav Laznicka wrote:
>> >>>>> On 08/11/2016 07:49 AM, Jan Cholasta wrote:
>> >>>>>> On 2.8.2016 13:47, Stanislav Laznicka wrote:
>> >>>>>>> On 07/19/2016 09:20 AM, Jan Cholasta wrote:
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>> On 14.7.2016 14:36, Stanislav Laznicka wrote:
>> >>>>>>>>> Hello,
>> >>>>>>>>>
>> >>>>>>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640.
>> >>>>>>>>>
>> >>>>>>>>> With not so much experience with the framework, it raises
>> >>>>>>>>> question
>> >>>>>>>>> in my
>> >>>>>>>>> head whether ipaldap.get_entries is used properly throughout the
>> >>>>>>>>> system
>> >>>>>>>>> - does it always assume that it gets ALL the requested entries or
>> >>>>>>>>> just a
>> >>>>>>>>> few of those as configured by the 'ipaSearchRecordsLimit'
>> >>>>>>>>> attribute of
>> >>>>>>>>> ipaConfig.etc which it actually gets?
>> >>>>>>>>
>> >>>>>>>> That depends. If you call get_entries() on the ldap2 plugin
>> >>>>>>>> (which is
>> >>>>>>>> usually the case in the framework), then ipaSearchRecordsLimit is
>> >>>>>>>> used. If you call it on some arbitrary LDAPClient instance, the
>> >>>>>>>> hardcoded default (= unlimited) is used.
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> One spot that I know the get_entries method was definitely not
>> >>>>>>>>> used
>> >>>>>>>>> properly before this patch is in the
>> >>>>>>>>> baseldap.LDAPObject.get_memberindirect() method:
>> >>>>>>>>>
>> >>>>>>>>> 692 result = self.backend.get_entries(
>> >>>>>>>>> 693 self.api.env.basedn,
>> >>>>>>>>> 694 filter=filter,
>> >>>>>>>>> 695 attrs_list=['member'],
>> >>>>>>>>> 696 size_limit=-1, # paged search will get
>> >>>>>>>>> everything
>> >>>>>>>>> anyway
>> >>>>>>>>> 697 paged_search=True)
>> >>>>>>>>>
>> >>>>>>>>> which to me seems kind of important if the environment size_limit
>> >>>>>>>>> is not
>> >>>>>>>>> set properly :) The patch does not fix the non-propagation of the
>> >>>>>>>>> paged_search, though.
>> >>>>>>>>
>> >>>>>>>> Why do you think size_limit is not used properly here?
>> >>>>>>> AFAIU it is desired that the search is unlimited. However, due
>> >>>>>>> to the
>> >>>>>>> fact that neither size_limit nor paged_search are passed from
>> >>>>>>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from
>> >>>>>>> LDAPClient), only the number of records specified by
>> >>>>>>> ipaSearchRecordsLimit is returned. That could eventually cause
>> >>>>>>> problems
>> >>>>>>> should ipaSearchRecordsLimit be set to a low value as in the
>> >>>>>>> ticket.
>> >>>>>>
>> >>>>>> I see. This is *not* intentional, the **kwargs of get_entries()
>> >>>>>> should be passed to find_entries(). This definitely needs to be
>> >>>>>> fixed.
>> >>>>>>
>> >>>>>>>>
>> >>>>>>>> Anyway, this ticket is not really easily fixable without more
>> >>>>>>>> profound
>> >>>>>>>> changes. Often, multiple LDAP searches are done during command
>> >>>>>>>> execution. What do you do with the size limit then? Do you pass
>> >>>>>>>> the
>> >>>>>>>> same size limit to all the searches? Do you subtract the result
>> >>>>>>>> size
>> >>>>>>>> from the size limit after each search? Do you do something else
>> >>>>>>>> with
>> >>>>>>>> it? ... The answer is that it depends on the purpose of each
>> >>>>>>>> individual LDAP search (like in get_memberindirect() above, we
>> >>>>>>>> have to
>> >>>>>>>> do unlimited search, otherwise the resulting entry would be
>> >>>>>>>> incomplete), and fixing this accross the whole framework is a
>> >>>>>>>> non-trivial task.
>> >>>>>>>>
>> >>>>>>> I do realize that the proposed fix for the permission plugin is not
>> >>>>>>> perfect, it would probably be better to subtract the number of
>> >>>>>>> currently
>> >>>>>>> loaded records from the sizelimit, although in the end the
>> >>>>>>> number of
>> >>>>>>> returned values will not be higher than the given size_limit.
>> >>>>>>> However,
>> >>>>>>> it seems reasonable that if get_entries is passed a size limit, it
>> >>>>>>> should apply it over current ipaSearchRecordsLimit rather than
>> >>>>>>> ignoring
>> >>>>>>> it. Then, any use of get_entries could be fixed accordingly if
>> >>>>>>> someone
>> >>>>>>> sees fit.
>> >>>>>>>
>> >>>>>>
>> >>>>>> Right. Anyway, this is a different issue than above, so please put
>> >>>>>> this into a separate commit.
>> >>>>>>
>> >>>>> Please see the attached patches, then.
>> >>>>>
>> >>>> Self-NACK, with Honza's help I found there was a mistake in the
>> >>>> code. I
>> >>>> also found an off-by-one bug which I hope I could stick to the
>> >>>> other two
>> >>>> patches (attaching only the modified and new patches).
>> >>>
>> >>> Works for me, but this bit in patch 0064 looks suspicious to me:
>> >>>
>> >>> + if max_entries > 0 and len(entries) ==
>> >>> max_entries:
>> >>>
>> >>> Shouldn't it rather be:
>> >>>
>> >>> + if max_entries > 0 and len(entries) >=
>> >>> max_entries:
>> >>>
>> >>> ?
>> >>>
>> >> The length of entries list should not exceed max_entries if size_limit
>> >> is properly implemented. Therefore the list you get from execute()
>> >> should not have more then max_entries entries. You shouldn't also be
>> >> able to append a legacy entry to entries list if this check is the first
>> >> thing you do.
>> >
>> > That's a lot of shoulds :-) I would expect at least an assert
>> > statement to make sure everything is right.
>> >
>> >>
>> >> That being said, >= could be used but then some popping of entries from
>> >> entries list would be necessary. But it's perhaps safer to do, although
>> >> if there's a bug, it won't be that obvious :)
>> >
>> > OK, nevermind then, just add the assert please, to make bugs *very*
>> > obvious.
>> >
>> An assert seems like a very good idea, attached is an asserting patch.
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: freeipa-slaznick-0064-2-permission-find-fix-a-
>> sizelimit-off-by-one-bug.patch
>> Type: text/x-patch
>> Size: 2640 bytes
>> Desc: not available
>> URL: <https://www.redhat.com/archives/freeipa-devel/
>> attachments/20161010/eddd5901/attachment.bin>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Mon, 10 Oct 2016 08:56:59 +0200
>> From: Petr Spacek <pspacek at redhat.com>
>> To: freeipa-devel at redhat.com
>> Subject: Re: [Freeipa-devel] kinit: Cannot contact any KDC for
>> realm... from Freeipa clinet (Active Directory trust setup)
>> Message-ID: <74136c2e-87aa-e18a-b16e-d2839ea126e4 at redhat.com>
>> Content-Type: text/plain; charset=windows-1252
>>
>> On 10.10.2016 05:23, rajat gupta wrote:
>> > Hi,
>> >
>> > I am trying to setup the freeipa Active Directory trust setup and i am
>> > following
>> > the http://www.freeipa.org/page/Active_Directory_trust_setup
>> documentation.
>> >
>> > I am able to login on freeipa Server with AD users.
>> >
>> > But when i am trying to login with some other IPA client machine I am not
>> > able to to login with AD user.
>> >
>> > Required firewall port is opened between freeipa server to AD server and
>> > freeipa server to freeipa clinets
>> >
>> > There is no firewall port is opened between from freeipa client to AD
>> > server.
>> >
>> > =================================================================
>> > against addomain from ipaserver :-
>> >
>> > ipa01 ~]# KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM
>> > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING
>> > [24633] 1476069033.463027: Getting initial credentials for
>> > rajat.g at AD.ADDOMAIN.COM
>> > [24633] 1476069033.465229: Sending request (183 bytes) to
>> AD.ADDOMAIN.COM
>> > [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com
>> > [24633] 1476069033.474439: Sending initial UDP request to dgram
>> > 192.168.20.100:88
>> > [24633] 1476069033.487765: Received answer (212 bytes) from dgram
>> > 192.168.20.100:88
>> > [24633] 1476069033.488098: Response was not from master KDC
>> > [24633] 1476069033.488136: Received error from KDC:
>> -1765328359/Additional
>> > pre-authentication required
>> > [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2
>> > [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt
>> > "AD.ADDOMAIN.COMRajat.Gupta", params ""
>> > [24633] 1476069033.488215: PKINIT client has no configured identity;
>> giving
>> > up
>> > [24633] 1476069033.488233: PKINIT client has no configured identity;
>> giving
>> > up
>> > [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned:
>> > 22/Invalid argument
>> > [24633] 1476069033.488250: PKINIT client has no configured identity;
>> giving
>> > up
>> > [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned:
>> > 22/Invalid argument
>> > Password for rajat.g at AD.ADDOMAIN.COM:
>> >
>> > this is working fine.
>> > =================================================================
>> >
>> >
>> > =================================================================
>> > against addomain from ipaclinet :-
>> >
>> > *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM
>> > <rajat.g at AD.ADDOMAIN.COM>[4133] 1476067599.43421: Getting initial
>> > credentials for rajat.g at AD.ADDOMAIN.COM <http://AD.ADDOMAIN.COM>[4133]
>> > 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM
>> > <http://AD.ADDOMAIN.COM>*
>> > *[4133] 1476067599.49544: Resolving hostname *
>> > *ad1.ad.addomain.com <http://ad1.ad.addomain.com>.*
>> > *[4133] 1476067599.53762: Sending initial UDP request to dgram
>> > 192.168.20.100*
>> >
>> > NOT WORKING
>> > =================================================================
>> >
>> > =================================================================
>> > against ipdomain from ipaclinet
>> >
>> > # KRB5_TRACE=/dev/stdout kinit admin at IPA.IPASERVER.LOCAL
>> > [4914] 1476068067.763574: Getting initial credentials for
>> > admin at IPA.IPASERVER.LOCAL
>> > [4914] 1476068067.763889: Sending request (177 bytes) to
>> IPA.IPASERVER.LOCAL
>> > [4914] 1476068067.764033: Initiating TCP connection to stream
>> > 10.246.104.14:88
>> > [4914] 1476068067.765089: Sending TCP request to stream
>> 192.168.100.100:88
>> > [4914] 1476068067.767593: Received answer (356 bytes) from stream
>> > 192.168.100.100:88
>> > [4914] 1476068067.767603: Terminating TCP connection to stream
>> > 192.168.100.100:88
>> > [4914] 1476068067.767661: Response was from master KDC
>> > [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional
>> > pre-authentication required
>> > [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133
>> > [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt
>> > "k},(k&+qA)Mosf6z", params ""
>> > [4914] 1476068067.767747: Received cookie: MIT
>> > Password for admin at IPA.IPASERVER.LOCAL:
>> >
>> > this is working fine.
>> > =================================================================
>> >
>> >
>> > it looks for password-based authentication requests, the IPA clients
>> > connect directly to the AD servers using Kerberos.
>> >
>> > then there is port firewall opening required between ipaclinet and AD
>> > Server as well. Is it required ? OR I am doing something wrong.
>>
>> Yes, IPA clients need to talk to AD servers as well. Please see
>> https://access.redhat.com/documentation/en-US/Red_Hat_
>> Enterprise_Linux/7/html/Windows_Integration_Guide/
>> trust-requirements.html#trust-req-ports
>>
>>
>> --
>> Petr^2 Spacek
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Mon, 10 Oct 2016 09:21:40 +0200
>> From: pvomacka <freeipa-github-notification at redhat.com>
>> To: freeipa-devel at redhat.com
>> Subject: [Freeipa-devel] [freeipa PR#146][opened] WebUI: fix API
>> Browser menu label
>> Message-ID:
>> <gh-freeipa/freeipa-146 at freeipa-github-notification.redhat.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> URL: https://github.com/freeipa/freeipa/pull/146
>> Author: pvomacka
>> Title: #146: WebUI: fix API Browser menu label
>> Action: opened
>>
>> PR body:
>> """
>> The label of API Browser is now in translatable strings and it has
>> uppercase B at the beginnig of second word.
>>
>> https://fedorahosted.org/freeipa/ticket/6384
>> """
>>
>> To pull the PR as Git branch:
>> git remote add ghfreeipa https://github.com/freeipa/freeipa
>> git fetch ghfreeipa pull/146/head:pr146
>> git checkout pr146
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: freeipa-pr-146.patch
>> Type: text/x-diff
>> Size: 2069 bytes
>> Desc: not available
>> URL: <https://www.redhat.com/archives/freeipa-devel/
>> attachments/20161010/5dc80c2e/attachment.bin>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>> End of Freeipa-devel Digest, Vol 113, Issue 35
>> **********************************************
>>
>
>
>
>--
>
>*Rajat Gupta *
>--
>Manage your subscription for the Freeipa-devel mailing list:
>https://www.redhat.com/mailman/listinfo/freeipa-devel
>Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
--
/ Alexander Bokovoy
More information about the Freeipa-devel
mailing list