[Freeipa-devel] Freeipa-devel Digest, Vol 113, Issue 35
rajat gupta
rajat.linux at gmail.com
Mon Oct 10 07:39:34 UTC 2016
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?
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 *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20161010/57f90141/attachment.htm>
More information about the Freeipa-devel
mailing list