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, <[email protected]> wrote: > Send Freeipa-devel mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Martin Basti <[email protected]>, freeipa-devel > <[email protected]> > Subject: Re: [Freeipa-devel] [PATCH 0497] Py3: fix unicode/str error > in LDAP*ReverseMember > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support > Message-ID: > <gh-freeipa/freeipa-134-2016-7bd42aa5-c029-4a55-b592- > [email protected]> > > 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 <[email protected]> > To: [email protected] > Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR > autogeneration > Message-ID: > <gh-freeipa/freeipa-10-2016-5d58c6bf-18d9-472a-a788- > [email protected]> > > 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 <[email protected]> > To: Jan Cholasta <[email protected]>, freeipa-devel > <[email protected]> > Subject: Re: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore > its size_limit argument > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: [Freeipa-devel] kinit: Cannot contact any KDC for > realm... from Freeipa clinet (Active Directory trust setup) > Message-ID: <[email protected]> > 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 [email protected] > > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING > > [24633] 1476069033.463027: Getting initial credentials for > > [email protected] > > [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 [email protected]: > > > > this is working fine. > > ================================================================= > > > > > > ================================================================= > > against addomain from ipaclinet :- > > > > *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit [email protected] > > <[email protected]>[4133] 1476067599.43421: Getting initial > > credentials for [email protected] <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 [email protected] > > [4914] 1476068067.763574: Getting initial credentials for > > [email protected] > > [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 [email protected]: > > > > 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 <[email protected]> > To: [email protected] > Subject: [Freeipa-devel] [freeipa PR#146][opened] WebUI: fix API > Browser menu label > Message-ID: > <gh-freeipa/[email protected]> > 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 > [email protected] > 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
