Re: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket
On Tue, 28 May 2013, Nicholas MacKenzie wrote:
Hello,
I have seen this happen on multiple fresh installs now. Can anyone shed any
light on it? I am unable to add a trust because of this, I assume. An
smbclient lookup against the DC works.
==
# ipa trust-add --type=ad ad.dc.com --admin username --password
Active directory domain administrator's password:
ipa: ERROR: Cannot find specified domain or server name
==
/var/log/httpd/error_log:
[Tue May 28 07:05:01 2013] [error] ipa: INFO: ad...@ipa.dc.com: trust_add(u'
ad.dc.sita.aero', trust_46'): NotFound
==
# ipactl restart
Restarting Directory Service
Shutting down dirsrv:
IPA-DC-COM.[ OK ]
PKI-IPA... [ OK ]
Starting dirsrv:
IPA-DC-COM ...[28/May/2013:07:09:24 +] ipa_cldap_init_service -
[file ipa_cldap.c, line 148]: Failed to create socket
What operating system is that?
Here is what we have in ipa_cldap.c:
ctx-sd = socket(PF_INET6, SOCK_DGRAM, 0);
if (ctx-sd == -1) {
LOG_FATAL(Failed to create socket\n);
ret = EIO;
goto done;
}
So we failed to create a socket using PF_INET6 family. It looks like you
don't have IPv6 enabled in your kernel?
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket
You were spot on about that. I enabled IPv6 and now the CLDAP plugin
installs fine. I am now faced with this...
dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED
Failed to bind to uuid 12345778-1234-abcd-ef00-0123456789ab for
12345778-1234-abcd-ef00-0123456789ab@ncacn_ip_tcp:
domain_controller.ad.dc.com[49500] NT_STATUS_NET_WRITE_FAULT
[Tue May 28 08:20:03 2013] [error] ipa: INFO: ad...@ipa.dc.com: trust_add(u'
ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username',
realm_passwd=u'', range_size=20, all=False, raw=False,
version=u'2.46'): ACIError
On Tue, May 28, 2013 at 3:46 AM, Alexander Bokovoy aboko...@redhat.comwrote:
On Tue, 28 May 2013, Nicholas MacKenzie wrote:
Hello,
I have seen this happen on multiple fresh installs now. Can anyone shed
any
light on it? I am unable to add a trust because of this, I assume. An
smbclient lookup against the DC works.
==
# ipa trust-add --type=ad ad.dc.com --admin username --password
Active directory domain administrator's password:
ipa: ERROR: Cannot find specified domain or server name
==
/var/log/httpd/error_log:
[Tue May 28 07:05:01 2013] [error] ipa: INFO: ad...@ipa.dc.com:
trust_add(u'
ad.dc.sita.aero', trust_46'): NotFound
==
# ipactl restart
Restarting Directory Service
Shutting down dirsrv:
IPA-DC-COM.[ OK ]
PKI-IPA... [ OK ]
Starting dirsrv:
IPA-DC-COM ...[28/May/2013:07:09:24 +] ipa_cldap_init_service -
[file ipa_cldap.c, line 148]: Failed to create socket
What operating system is that?
Here is what we have in ipa_cldap.c:
ctx-sd = socket(PF_INET6, SOCK_DGRAM, 0);
if (ctx-sd == -1) {
LOG_FATAL(Failed to create socket\n);
ret = EIO;
goto done;
}
So we failed to create a socket using PF_INET6 family. It looks like you
don't have IPv6 enabled in your kernel?
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket
Nevermind. I used the Administrator account and all is well. This is a
lovely site.
Added Active Directory trust for realm ad.dc.com
Realm name: ad.dc.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-1226121717-3896983829-760149474
Trust direction: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified
On Tue, May 28, 2013 at 4:24 AM, Nicholas MacKenzie nic...@gmail.comwrote:
You were spot on about that. I enabled IPv6 and now the CLDAP plugin
installs fine. I am now faced with this...
dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED
Failed to bind to uuid 12345778-1234-abcd-ef00-0123456789ab for
12345778-1234-abcd-ef00-0123456789ab@ncacn_ip_tcp:
domain_controller.ad.dc.com[49500] NT_STATUS_NET_WRITE_FAULT
[Tue May 28 08:20:03 2013] [error] ipa: INFO: ad...@ipa.dc.com:
trust_add(u'ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username',
realm_passwd=u'', range_size=20, all=False, raw=False,
version=u'2.46'): ACIError
On Tue, May 28, 2013 at 3:46 AM, Alexander Bokovoy aboko...@redhat.comwrote:
On Tue, 28 May 2013, Nicholas MacKenzie wrote:
Hello,
I have seen this happen on multiple fresh installs now. Can anyone shed
any
light on it? I am unable to add a trust because of this, I assume. An
smbclient lookup against the DC works.
==
# ipa trust-add --type=ad ad.dc.com --admin username --password
Active directory domain administrator's password:
ipa: ERROR: Cannot find specified domain or server name
==
/var/log/httpd/error_log:
[Tue May 28 07:05:01 2013] [error] ipa: INFO: ad...@ipa.dc.com:
trust_add(u'
ad.dc.sita.aero', trust_46'): NotFound
==
# ipactl restart
Restarting Directory Service
Shutting down dirsrv:
IPA-DC-COM.[ OK ]
PKI-IPA... [ OK ]
Starting dirsrv:
IPA-DC-COM ...[28/May/2013:07:09:24 +] ipa_cldap_init_service -
[file ipa_cldap.c, line 148]: Failed to create socket
What operating system is that?
Here is what we have in ipa_cldap.c:
ctx-sd = socket(PF_INET6, SOCK_DGRAM, 0);
if (ctx-sd == -1) {
LOG_FATAL(Failed to create socket\n);
ret = EIO;
goto done;
}
So we failed to create a socket using PF_INET6 family. It looks like you
don't have IPv6 enabled in your kernel?
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket
On Tue, 28 May 2013, Nicholas MacKenzie wrote: You were spot on about that. I enabled IPv6 and now the CLDAP plugin installs fine. I am now faced with this... dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED Failed to bind to uuid 12345778-1234-abcd-ef00-0123456789ab for 12345778-1234-abcd-ef00-0123456789ab@ncacn_ip_tcp: domain_controller.ad.dc.com[49500] NT_STATUS_NET_WRITE_FAULT [Tue May 28 08:20:03 2013] [error] ipa: INFO: ad...@ipa.dc.com: trust_add(u' ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username', realm_passwd=u'', range_size=20, all=False, raw=False, version=u'2.46'): ACIError Specify your AD admin username fully-qualified, either DOMAIN\username or username@REALM. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Patchwork] command line client
On 27.5.2013 22:05, Simo Sorce wrote: On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: On 27.5.2013 15:57, Simo Sorce wrote: On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: Hello Simo, could you install/allow XMLRPC for our Patchwork, please? I found the CLI for Patchwork but it requires XMLRPC. On 27.5.2013 10:41, Petr Spacek wrote: see https://www.varnish-cache.org/patchwork/help/pwclient/ Should be enabled now. Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): xmlrpclib.ProtocolError: ProtocolError for patchwork.acksyn.org/xmlrpc/: 404 NOT FOUND I've restarted the apahe server, apparently not all threads would see the new config w/o a full reload. I confirm that it works now. BTW did you considered migration to freeipa.org? :-) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0155] Fix IPv6 handling in PTR record synchronization
ACK The patch looks good and works as expected. Regards, Tomas Hozza - Original Message - Hello, Fix IPv6 handling in PTR record synchronization. https://fedorahosted.org/bind-dyndb-ldap/ticket/118 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Patchwork] command line client
On 05/28/2013 10:38 AM, Petr Spacek wrote: On 27.5.2013 22:05, Simo Sorce wrote: On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: On 27.5.2013 15:57, Simo Sorce wrote: On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: Hello Simo, could you install/allow XMLRPC for our Patchwork, please? I found the CLI for Patchwork but it requires XMLRPC. On 27.5.2013 10:41, Petr Spacek wrote: see https://www.varnish-cache.org/patchwork/help/pwclient/ Should be enabled now. Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): xmlrpclib.ProtocolError: ProtocolError for patchwork.acksyn.org/xmlrpc/: 404 NOT FOUND I've restarted the apahe server, apparently not all threads would see the new config w/o a full reload. I confirm that it works now. BTW did you considered migration to freeipa.org? :-) We could eventually migrate it to OpenShift just like FreeIPA.org's mediawiki site. As patchwork is based on Django which is common on OpenShift, it should not be so difficult. We could then create alias patchwork.freeipa.org if we want to use it. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show
On 05/27/2013 03:04 PM, Ana Krivokapic wrote:
On 05/27/2013 02:38 PM, Tomas Babej wrote:
Hi,
In trust_show command, make sure that --raw flag is honoured.
Attributes ipanttrusttype and ipanttrustdirection are no longer
translated to strings from their raw ldap values when --raw is
used.
https://fedorahosted.org/freeipa/ticket/3525
Tomas
The patch causes these two attributes to not be displayed, when --raw
switch is used:
[akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com
Realm name: addomain.example.com
Domain NetBIOS name: ADDOMAIN
Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322
Trust direction: Two-way trust
Trust type: Active Directory domain
[akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com --raw
cn: addomain.example.com
ipantflatname: ADDOMAIN
ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322
Thanks. Updated patch attached.
I modified trust-find according to the new behaviour.
Tomas
From df9267f820748e36f7fbfb0f4248b99f874ccd2f Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 27 May 2013 14:21:57 +0200
Subject: [PATCH] Do not translate trust type and direction with --raw in
trust_show
In trust_show command, make sure that --raw flag is honoured.
Attributes ipanttrusttype and ipanttrustdirection are no longer
translated to strings from their raw ldap values when --raw is
used.
https://fedorahosted.org/freeipa/ticket/3525
---
ipalib/plugins/trust.py | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 9bcfb417a9413faffdeb4009d9de06d6041b223e..3cb0ed98005ae5bd11b39f8ae01c9470d1bfc9c4 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -487,7 +487,8 @@ class trust_mod(LDAPUpdate):
class trust_find(LDAPSearch):
__doc__ = _('Search for trusts.')
-has_output_params = LDAPSearch.has_output_params + trust_output_params
+has_output_params = LDAPSearch.has_output_params + trust_output_params +\
+(Str('ipanttrusttype'),)
msg_summary = ngettext(
'%(count)d trust matched', '%(count)d trusts matched', 0
@@ -505,13 +506,18 @@ class trust_find(LDAPSearch):
for entry in entries:
(dn, attrs) = entry
-attrs['trusttype'] = trust_type_string(attrs['ipanttrusttype'][0])
+
+# Translate ipanttrusttype to trusttype if --raw not used
+if not options.get('raw', False):
+attrs['trusttype'] = trust_type_string(attrs['ipanttrusttype'][0])
+del attrs['ipanttrusttype']
return truncated
class trust_show(LDAPRetrieve):
__doc__ = _('Display information about a trust.')
-has_output_params = LDAPRetrieve.has_output_params + trust_output_params
+has_output_params = LDAPRetrieve.has_output_params + trust_output_params +\
+(Str('ipanttrusttype'), Str('ipanttrustdirection'))
def execute(self, *keys, **options):
error = None
@@ -524,9 +530,7 @@ class trust_show(LDAPRetrieve):
result = None
error = e
if result:
- result['result']['trusttype'] = [trust_type_string(result['result']['ipanttrusttype'][0])]
- result['result']['trustdirection'] = [trust_direction_string(result['result']['ipanttrustdirection'][0])]
- break
+break
if error or not result:
self.obj.handle_not_found(*keys)
@@ -536,6 +540,24 @@ class trust_show(LDAPRetrieve):
assert isinstance(dn, DN)
if 'trust_show_type' in options:
return make_trust_dn(self.env, options['trust_show_type'], dn)
+
+return dn
+
+def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
+
+# Translate ipanttrusttype to trusttype
+# and ipanttrustdirection to trustdirection
+# if --raw not used
+
+if not options.get('raw', False):
+type_str = trust_type_string(entry_attrs['ipanttrusttype'][0])
+dir_str = trust_direction_string(entry_attrs['ipanttrustdirection']
+[0])
+entry_attrs['trusttype'] = [type_str]
+entry_attrs['trustdirection'] = [dir_str]
+del entry_attrs['ipanttrusttype']
+del entry_attrs['ipanttrustdirection']
+
return dn
api.register(trust)
--
1.8.1.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Patchwork] command line client
On Tue, 2013-05-28 at 10:46 +0200, Martin Kosek wrote: On 05/28/2013 10:38 AM, Petr Spacek wrote: On 27.5.2013 22:05, Simo Sorce wrote: On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: On 27.5.2013 15:57, Simo Sorce wrote: On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: Hello Simo, could you install/allow XMLRPC for our Patchwork, please? I found the CLI for Patchwork but it requires XMLRPC. On 27.5.2013 10:41, Petr Spacek wrote: see https://www.varnish-cache.org/patchwork/help/pwclient/ Should be enabled now. Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): xmlrpclib.ProtocolError: ProtocolError for patchwork.acksyn.org/xmlrpc/: 404 NOT FOUND I've restarted the apahe server, apparently not all threads would see the new config w/o a full reload. I confirm that it works now. BTW did you considered migration to freeipa.org? :-) We could eventually migrate it to OpenShift just like FreeIPA.org's mediawiki site. As patchwork is based on Django which is common on OpenShift, it should not be so difficult. We could then create alias patchwork.freeipa.org if we want to use it. Yup, I think we should do it, Petr are you ihnterested in comaintainng it if we move it to an OpenShift instance ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) Nitpick -- currently this is planned for 1.11 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust
On Mon, 27 May 2013, Tomas Babej wrote:
We got rid of openldap utilities now. While using python.ldap
module, I also made the tests much more robust and added a new
test case.
In general patches look fine, there is one small nitpick.
I'll run tests on Monday and then will provide final ACK.
--- a/tests/test_xmlrpc/test_range_plugin.py
+++ b/tests/test_xmlrpc/test_range_plugin.py
@@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py`
module, and XML-RPC in general.
from ipalib import api, errors, _
+from ipapython.ipautil import run
This import is unused, can be removed.
Fixed, thanks for catching that.
Updated patch attached.
So I tried to run this test on a machine where there is already trust
established and I think there should be done some changes.
Probably it would be wise to add pre-start procedure to pull existing
ranges and define constants for the ranges so that they don't overlap
with existing ones. Perhaps selecting something from a top of the range
space...
Attached is the log.
--
/ Alexander Bokovoy
test_range pre-cleanup[0]: ('idrange_del', [u'testrange1', u'testrange2',
u'testrange3', u'testrange4', u'testrange5', u'testrange6', u'testrange7',
u'testrange8'], {'continue': True}) ... ok
test_range pre-cleanup[1]: ('user_del', [u'tuser1'], {}) ... ok
test_range pre-cleanup[2]: ('group_del', [u'group1'], {}) ... ok
test_range[0]: idrange_add: Create ID range u'testrange1' ... ERROR
test_range[1]: idrange_show: Retrieve ID range u'testrange1' ... ERROR
test_range[2]: user_add: Create user u'tuser1' in ID range u'testrange1' ... ok
test_range[3]: group_add: Create group u'group1' in ID range u'testrange1' ...
ok
test_range[4]: idrange_mod: Try to modify ID range u'testrange1' to get out
bounds object #1 ... FAIL
test_range[5]: idrange_mod: Try to modify ID range u'testrange1' to get out
bounds object #2 ... FAIL
test_range[6]: idrange_mod: Try to modify ID range u'testrange1' to get out
bounds object #3 ... FAIL
test_range[7]: idrange_mod: Modify ID range u'testrange1' ... ERROR
test_range[8]: idrange_del: Try to delete ID range u'testrange1' with active
IDs inside it ... FAIL
test_range[9]: user_del: Delete user u'tuser1' ... ok
test_range[10]: group_del: Delete group u'group1' ... ok
test_range[11]: idrange_del: Delete ID range u'testrange1' ... ERROR
test_range[12]: idrange_add: Create ID range u'testrange2' ... ERROR
test_range[13]: idrange_mod: Try to modify ID range u'testrange2' so that its
rid ranges are overlapping themselves ... FAIL
test_range[14]: idrange_add: Try to create ID range u'testrange3' with
overlapping rid range ... FAIL
test_range[15]: idrange_add: Try to create ID range u'testrange4' with
overlapping secondary rid range ... FAIL
test_range[16]: idrange_add: Try to create ID range u'testrange5' with primary
range overlapping secondary rid range ... FAIL
test_range[17]: idrange_add: Try to create ID range u'testrange6' with
overlapping id range ... FAIL
test_range[18]: idrange_add: Try to create ID range u'testrange7' with rid
ranges overlapping themselves ... ok
test_range[19]: idrange_del: Delete ID range u'testrange2' ... ERROR
test_range[20]: idrange_add: Create ID range u'testrange8' ... ok
test_range[21]: idrange_mod: Try to modify ID range u'testrange8' so it has
only primary rid range set ... ok
test_range[22]: idrange_del: Delete ID range u'testrange8' ... ok
test_range[23]: idrange_del: Delete non-active AD trusted range u'testrange9'
... ok
test_range[24]: idrange_del: Try to delete active AD trusted range
u'testrange10' ... ok
test_range post-cleanup[0]: ('idrange_del', [u'testrange1', u'testrange2',
u'testrange3', u'testrange4', u'testrange5', u'testrange6', u'testrange7',
u'testrange8'], {'continue': True}) ... ok
test_range post-cleanup[1]: ('user_del', [u'tuser1'], {}) ... ok
test_range post-cleanup[2]: ('group_del', [u'group1'], {}) ... ok
==
ERROR: test_range[0]: idrange_add: Create ID range u'testrange1'
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File
/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py,
line 271, in lambda
func = lambda: self.check(nice, **test)
File
/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py,
line 289, in check
self.check_output(nice, cmd, args, options, expected, extra_check)
File
/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py,
line 326, in check_output
got = api.Command[cmd](*args, **options)
File /root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py, line
436, in __call__
ret = self.run(*args, **options)
File /root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py, line
735, in run
return self.forward(*args,
Re: [Freeipa-devel] CLDAP Netlogon fixes
On Thu, 23 May 2013, Simo Sorce wrote: As you can see, incorrect parameters still return empty dn and netlogon attributes while Windows Server 2012 returns empty response: $ ldapsearch -LL -H cldap://altai.ad.lan -b -s base '((NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon version: 1 Yet, since for trusts we care about explicit request with our domain name _and_ the case when DnsDomain is not specified, everything continues to work. So ACK. I can easily avoid returning the empty netlogon field, which is what I wanted to do. I'll see if I can also avoid returning the DN. Let me try just one more revision. It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY completely as they were supposed to, and only return a LDAP_RES_SEARCH_RESULT record. Thanks. Tested and it works fine. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust
On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: On Mon, 27 May 2013, Tomas Babej wrote: We got rid of openldap utilities now. While using python.ldap module, I also made the tests much more robust and added a new test case. In general patches look fine, there is one small nitpick. I'll run tests on Monday and then will provide final ACK. --- a/tests/test_xmlrpc/test_range_plugin.py +++ b/tests/test_xmlrpc/test_range_plugin.py @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and XML-RPC in general. from ipalib import api, errors, _ +from ipapython.ipautil import run This import is unused, can be removed. Fixed, thanks for catching that. Updated patch attached. So I tried to run this test on a machine where there is already trust established and I think there should be done some changes. I perused the log. Seems that the failures you're experiencing are not relevant to the patch itself, since the newly added tests passed. This is problem with test_range_plugin.py tests that has been there for quite a while, the parameters of the ranges such as size, and base ID/RID/secondary RID are hardcoded in the test case. Probably it would be wise to add pre-start procedure to pull existing ranges and define constants for the ranges so that they don't overlap with existing ones. Perhaps selecting something from a top of the range space... Attached is the log I agree. This has not been relevant until now, since we did not do much testing on IPA instances with trusts set up, and even then there's random factor in having the overlap with the already created trust range. I'd propose fixing this in a separate effort as a part of continouous integration improvements. I see it as a separate issue of its own. What do you think? Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust
On Tue, 28 May 2013, Tomas Babej wrote: On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: On Mon, 27 May 2013, Tomas Babej wrote: We got rid of openldap utilities now. While using python.ldap module, I also made the tests much more robust and added a new test case. In general patches look fine, there is one small nitpick. I'll run tests on Monday and then will provide final ACK. --- a/tests/test_xmlrpc/test_range_plugin.py +++ b/tests/test_xmlrpc/test_range_plugin.py @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and XML-RPC in general. from ipalib import api, errors, _ +from ipapython.ipautil import run This import is unused, can be removed. Fixed, thanks for catching that. Updated patch attached. So I tried to run this test on a machine where there is already trust established and I think there should be done some changes. I perused the log. Seems that the failures you're experiencing are not relevant to the patch itself, since the newly added tests passed. This is problem with test_range_plugin.py tests that has been there for quite a while, the parameters of the ranges such as size, and base ID/RID/secondary RID are hardcoded in the test case. Yep. Probably it would be wise to add pre-start procedure to pull existing ranges and define constants for the ranges so that they don't overlap with existing ones. Perhaps selecting something from a top of the range space... Attached is the log I agree. This has not been relevant until now, since we did not do much testing on IPA instances with trusts set up, and even then there's random factor in having the overlap with the already created trust range. I'd propose fixing this in a separate effort as a part of continouous integration improvements. I see it as a separate issue of its own. What do you think? Please file a separate ticket then. ACK for this one. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0159] Deprecate configuration without persistent search
Hello,
Deprecate configuration without persistent search.
https://fedorahosted.org/bind-dyndb-ldap/ticket/120
--
Petr^2 Spacek
From 316918a5b8ffec4f5db97cc0c44a9445b55e5d13 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Tue, 28 May 2013 15:54:24 +0200
Subject: [PATCH] Deprecate configuration without persistent search.
https://fedorahosted.org/bind-dyndb-ldap/ticket/120
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 0de62025e67d466a5c656ce8a5d6b3042fadce67..424bc4b8afef924e92524ceca620e047380d70a4 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -386,6 +386,10 @@ validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) {
/* watcher needs one and update_*() requests second connection */
CLEANUP_WITH(ISC_R_RANGE);
}
+ if (!psearch)
+ log_info(configuration without persistent search is deprecated
+ and the support for zone_refresh will be removed
+ in the future);
CHECK(setting_get_bool(serial_autoincrement, set, serial_autoincrement));
if (serial_autoincrement !psearch) {
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] CLDAP Netlogon fixes
On 05/28/2013 04:12 PM, Martin Kosek wrote: On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: On Thu, 23 May 2013, Simo Sorce wrote: As you can see, incorrect parameters still return empty dn and netlogon attributes while Windows Server 2012 returns empty response: $ ldapsearch -LL -H cldap://altai.ad.lan -b -s base '((NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon version: 1 Yet, since for trusts we care about explicit request with our domain name _and_ the case when DnsDomain is not specified, everything continues to work. So ACK. I can easily avoid returning the empty netlogon field, which is what I wanted to do. I'll see if I can also avoid returning the DN. Let me try just one more revision. It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY completely as they were supposed to, and only return a LDAP_RES_SEARCH_RESULT record. Thanks. Tested and it works fine. ACK. Pushed to master, ipa-3-1, ipa-3-0. Sorry, off-by-one error :-) The actual branches where I pushed this were master, ipa-3-2 and ipa-3-1. Martin I will release 3.1.5 soon to Fedora 18 to fix cooperation with realmd. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] CLDAP Netlogon fixes
On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: On Thu, 23 May 2013, Simo Sorce wrote: As you can see, incorrect parameters still return empty dn and netlogon attributes while Windows Server 2012 returns empty response: $ ldapsearch -LL -H cldap://altai.ad.lan -b -s base '((NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon version: 1 Yet, since for trusts we care about explicit request with our domain name _and_ the case when DnsDomain is not specified, everything continues to work. So ACK. I can easily avoid returning the empty netlogon field, which is what I wanted to do. I'll see if I can also avoid returning the DN. Let me try just one more revision. It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY completely as they were supposed to, and only return a LDAP_RES_SEARCH_RESULT record. Thanks. Tested and it works fine. ACK. Pushed to master, ipa-3-1, ipa-3-0. I will release 3.1.5 soon to Fedora 18 to fix cooperation with realmd. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0059] Make testcert automagically when needed by unit test
On 05/27/2013 04:07 PM, Tomas Babej wrote:
On 05/24/2013 02:02 PM, Petr Viktorin wrote:
On 05/24/2013 09:57 AM, Tomas Babej wrote:
On 05/23/2013 07:17 PM, Tomas Babej wrote:
Hi,
With this patch, there's no need to run make-testcert separately
before running make-test. Unit test framework will check whether
service.crt file exists, and if not, will generate one if needed.
New location of service.crt file is in ~/.ipa directory.
Part of https://fedorahosted.org/freeipa/ticket/3621
Tomas
Thanks, it works well.
However it would be nice to not repeat this code in every test that
needs the cert:
+servercert = ''
+
+# Create the testing server cert if it does not already exist
+# Returns True if successful, error message if not
+if not os.path.exists(testcert.CERTPATH):
+servercert_ret = testcert.main()
+
+if os.path.exists(testcert.CERTPATH):
+fd = open(testcert.CERTPATH, 'r')
+servercert = fd.readlines()
+servercert = ''.join(servercert)
+servercert = x509.strip_header(servercert)
+fd.close()
+
+
Please put this in testcert.py and just call something like
`servercert = testcert.get_testcert()`.
class test_host(Declarative):
+def setUp(self):
+super(Declarative, self).setUp()
+if servercert == '':
+raise nose.SkipTest('Testcert generation problem: %s' %
+ servercert_ret)
+
Do we really want to skip the test here? IMO if we cannot generate the
cert, we should fail (`assert servercert`).
Thank you for the comments.
Updated patch attached.
Tomas
Okay, I ran it again.
Please also remove make-testcert from the Makefile.
I now get lots of errors from the test suite, starting with these:
cannot connect to
'https://vm-050.idm.lab.bos.redhat.com:443/ca/eeca/ca/profileSubmitSSLClient':
[Errno -8054] (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) You are attempting to
import a cert with the same issuer/serial as an existing cert, but that
is not the same cert.
Does this not happen in your setup?
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists
Hello,
This patch addresses https://fedorahosted.org/freeipa/ticket/3634
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From d22fe354c901e7ab47a7a53270a43ca8baf1b03f Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Tue, 28 May 2013 16:42:03 +0200
Subject: [PATCH] Require rid-base and secondary-rid-base options in
idrange-add when trust exists
https://fedorahosted.org/freeipa/ticket/3634
---
ipalib/plugins/idrange.py | 41 +-
tests/test_cmdline/test_cli.py | 50 ++
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index 54f6fbb3e19b9aa01dfde2a8d0c5da4498632386..4b2221ad45f1d1a62d0ac9ff4e180022d204bab4 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -342,7 +342,7 @@ class idrange_add(LDAPCreate):
may be given for a new ID range for the local domain while
---rid-bas
+--rid-base
--dom-sid
must be given to add a new range for a trusted AD domain.
@@ -361,6 +361,31 @@ class idrange_add(LDAPCreate):
msg_summary = _('Added ID range %(value)s')
+def interactive_prompt_callback(self, kw):
+
+Interactive mode should prompt for rid-base and secondary-rid-base
+if a trust is established.
+
+trust_exists = api.Command['trust_find']()['count']
+
+if not trust_exists:
+return
+
+rid_base = kw.get('ipabaserid', None)
+secondary_rid_base = kw.get('ipasecondarybaserid', None)
+
+if rid_base is None:
+rid_base = self.Backend.textui.prompt(
+_(u'First RID of the corresponding RID range')
+)
+kw['ipabaserid'] = rid_base
+
+if secondary_rid_base is None:
+secondary_rid_base = self.Backend.textui.prompt(
+_(u'First RID of the secondary RID range')
+)
+kw['ipasecondarybaserid'] = secondary_rid_base
+
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
assert isinstance(dn, DN)
@@ -418,6 +443,20 @@ def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
error=_(Primary RID range and secondary RID range
cannot overlap))
+# If a trust is established, base rid and secondary base rid
+# must be specified for local id range
+trust_exists = api.Command['trust_find']()['count']
+
+if trust_exists and not (
+is_set('ipabaserid') and is_set('ipasecondarybaserid')):
+raise errors.ValidationError(
+name='ID Range setup',
+error=_('You must specify both rid-base and '
+'secondary-rid-base options, because a trust is '
+'established.'
+)
+)
+
entry_attrs['objectclass'].append('ipadomainidrange')
return dn
diff --git a/tests/test_cmdline/test_cli.py b/tests/test_cmdline/test_cli.py
index bd1281e1d682b055ede9685a10a9cec91a3c76fd..7137ff4573f7de7699b0ff0b6ec86b305af49e00 100644
--- a/tests/test_cmdline/test_cli.py
+++ b/tests/test_cmdline/test_cli.py
@@ -325,3 +325,53 @@ def test_dnszone_add(self):
force=False,
version=API_VERSION
)
+
+def test_idrange_add(self):
+
+Test idrange-add with interative prompt
+
+trust_exists = api.Command['trust_find']()['count']
+
+if trust_exists:
+# Pass rid-base and secondary-rid-base interactively
+with self.fake_stdin('5\n50\n'):
+self.check_command(
+'idrange_add range1 --base-id=1 --range-size=1',
+'idrange_add',
+cn=u'range1',
+ipabaseid=u'1',
+ipaidrangesize=u'1',
+ipabaserid=u'5',
+ipasecondarybaserid=u'50',
+all=False,
+raw=False,
+version=API_VERSION
+)
+
+# Pass rid-base and secondary-rid-base on the command-line
+self.check_command(
+'idrange_add range1 --base-id=1 --range-size=1 '
+'--rid-base=5 --secondary-rid-base=50',
+'idrange_add',
+cn=u'range1',
+ipabaseid=u'1',
+ipaidrangesize=u'1',
+ipabaserid=u'5',
+ipasecondarybaserid=u'50',
+all=False,
+raw=False,
+version=API_VERSION
+)
+else:
+# Trust not established - no need to pass rid-base
+# and secondary-rid-base
+
Re: [Freeipa-devel] CLDAP Netlogon fixes
On 05/28/2013 04:13 PM, Martin Kosek wrote: On 05/28/2013 04:12 PM, Martin Kosek wrote: On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: On Thu, 23 May 2013, Simo Sorce wrote: As you can see, incorrect parameters still return empty dn and netlogon attributes while Windows Server 2012 returns empty response: $ ldapsearch -LL -H cldap://altai.ad.lan -b -s base '((NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon version: 1 Yet, since for trusts we care about explicit request with our domain name _and_ the case when DnsDomain is not specified, everything continues to work. So ACK. I can easily avoid returning the empty netlogon field, which is what I wanted to do. I'll see if I can also avoid returning the DN. Let me try just one more revision. It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY completely as they were supposed to, and only return a LDAP_RES_SEARCH_RESULT record. Thanks. Tested and it works fine. ACK. Pushed to master, ipa-3-1, ipa-3-0. Sorry, off-by-one error :-) The actual branches where I pushed this were master, ipa-3-2 and ipa-3-1. Martin I will release 3.1.5 soon to Fedora 18 to fix cooperation with realmd. Martin I just noticed a strange behavior when I was sanity testing upcoming 3.1.5 release: # ldapsearch -LL -H cldap://vm-037.idm.lab.bos.redhat.com -b -s base '((DnsDomain=foo)(NtVer=\06\00\00\00)(AAC=\00\00\00\00))' version: 1 # ... this looks correct. But following call hangs: # ldapsearch -LL -H cldap://vm-037.idm.lab.bos.redhat.com -b -s base '(NtVer=\06\00\00\00)' version: 1 ^C This does not look right. Am I doing something wrong? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show
On 05/28/2013 01:20 PM, Tomas Babej wrote: On 05/27/2013 03:04 PM, Ana Krivokapic wrote: On 05/27/2013 02:38 PM, Tomas Babej wrote: Hi, In trust_show command, make sure that --raw flag is honoured. Attributes ipanttrusttype and ipanttrustdirection are no longer translated to strings from their raw ldap values when --raw is used. https://fedorahosted.org/freeipa/ticket/3525 Tomas The patch causes these two attributes to not be displayed, when --raw switch is used: [akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com Realm name: addomain.example.com Domain NetBIOS name: ADDOMAIN Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322 Trust direction: Two-way trust Trust type: Active Directory domain [akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com --raw cn: addomain.example.com ipantflatname: ADDOMAIN ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322 Thanks. Updated patch attached. I modified trust-find according to the new behaviour. Tomas Works nicely. Please just amend the commit message to mention that the trust-find command is also affected. ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Patchwork] command line client
On Mon, 2013-05-27 at 09:57 -0400, Simo Sorce wrote: On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: Hello Simo, could you install/allow XMLRPC for our Patchwork, please? I found the CLI for Patchwork but it requires XMLRPC. On 27.5.2013 10:41, Petr Spacek wrote: see https://www.varnish-cache.org/patchwork/help/pwclient/ Should be enabled now. Btw, I may need to put the patchwork instance in maintenance mode on Wednesday. The extent of the outage will depend on the amount of work needed to replace a hard drive. Will try to keep the list posted. Server is now down for maintenance. Should be up in a few hours. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Patchwork] command line client
On Tue, 2013-05-28 at 12:19 -0400, Simo Sorce wrote: On Mon, 2013-05-27 at 09:57 -0400, Simo Sorce wrote: On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: Hello Simo, could you install/allow XMLRPC for our Patchwork, please? I found the CLI for Patchwork but it requires XMLRPC. On 27.5.2013 10:41, Petr Spacek wrote: see https://www.varnish-cache.org/patchwork/help/pwclient/ Should be enabled now. Btw, I may need to put the patchwork instance in maintenance mode on Wednesday. The extent of the outage will depend on the amount of work needed to replace a hard drive. Will try to keep the list posted. Server is now down for maintenance. Should be up in a few hours. The server is back up. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. Alternatively we should modify KDC to use the new extop and go though the SSSD on the IPA side but I do not see it mentioned anywhere. Can we get a bit more clarity about the Kerberos authentication workflow? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? I'm talking about the case when AD user logs in into IPA client using PuTTY from Windows machine. In such case there is already service ticket and cross-realm TGT available. For kinit on IPA client all what is needed is /etc/krb5.conf
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? I'm talking about the case when AD user logs in into IPA client using PuTTY from
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? I'm talking about the case when AD user logs in into IPA client using PuTTY from Windows machine. In such case there is already service ticket and
