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-requ...@redhat.com> wrote:

Send Freeipa-devel mailing list submissions to
        freeipa-devel@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-requ...@redhat.com

You can reach the person managing the list at
        freeipa-devel-ow...@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 <jchol...@redhat.com>
To: Martin Basti <mba...@redhat.com>, freeipa-devel
        <freeipa-devel@redhat.com>
Subject: Re: [Freeipa-devel] [PATCH 0497] Py3: fix unicode/str error
        in LDAP*ReverseMember
Message-ID: <ac85aef1-231b-d5a2-37c0-44c7250e5...@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-notificat...@redhat.com>
To: freeipa-devel@redhat.com
Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support
Message-ID:
        <gh-freeipa/freeipa-134-2016-7bd42aa5-c029-4a55-b592-
ca678c7db...@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-notificat...@redhat.com>
To: freeipa-devel@redhat.com
Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR
        autogeneration
Message-ID:
        <gh-freeipa/freeipa-10-2016-5d58c6bf-18d9-472a-a788-
8b40194d7...@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 <slazn...@redhat.com>
To: Jan Cholasta <jchol...@redhat.com>, freeipa-devel
        <freeipa-devel@redhat.com>
Subject: Re: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore
        its size_limit argument
Message-ID: <c552597b-df9f-0ce0-34b5-44b9c3c9d...@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 <pspa...@redhat.com>
To: freeipa-devel@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-d2839ea12...@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 raja...@ad.addomain.com
> [24633] 1476069033.462976: Resolving unique ccache of type KEYRING
> [24633] 1476069033.463027: Getting initial credentials for
> raja...@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 raja...@ad.addomain.com:
>
> this is working fine.
> =================================================================
>
>
> =================================================================
> against addomain from ipaclinet :-
>
> *ipaclinet ~] #  KRB5_TRACE=/dev/stdout kinit  raja...@ad.addomain.com
> <raja...@ad.addomain.com>[4133] 1476067599.43421: Getting initial
> credentials for raja...@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@IPA.IPASERVER.LOCAL
> [4914] 1476068067.763574: Getting initial credentials for
> admin@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@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-notificat...@redhat.com>
To: freeipa-devel@redhat.com
Subject: [Freeipa-devel] [freeipa PR#146][opened] WebUI: fix API
        Browser menu label
Message-ID:
        <gh-freeipa/freeipa-...@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@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

--
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

Reply via email to