Re: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms
On 11/15/2012 11:54 AM, Tomas Babej wrote: Hi, This is server part of #3252. When user from other realm than FreeIPA's tries to use Web UI (login via forms-based auth or with valid trusted realm ticket), the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied is returned. Also, the support for usernames of the form user@SERVER.REALM or user@server.realm was added. https://fedorahosted.org/freeipa/ticket/3252 Tomas +# allows login in the form user@SERVER_REALM or FIXME:user@server_realm The comment may not be clear for other people. I would be more verbose about the FIXME. +parts = user.split(@) +if len(parts) 1: +if parts[1].upper()==self.api.env.realm: I don't think we wanted to do this hard-check of realm. Personally I'am not against it because it's better to fail at login than at subsequent command (which will happen). Anyway it should be commented. +user=parts[0] +else: +return self.unauthorized(environ, start_response, '', 'denied') -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms
On 11/15/2012 12:41 PM, Petr Vobornik wrote:
On 11/15/2012 11:54 AM, Tomas Babej wrote:
Hi,
This is server part of #3252.
When user from other realm than FreeIPA's tries to use Web UI
(login via forms-based auth or with valid trusted realm ticket),
the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied
is returned.
Also, the support for usernames of the form user@SERVER.REALM
or user@server.realm was added.
https://fedorahosted.org/freeipa/ticket/3252
Tomas
+# allows login in the form user@SERVER_REALM or
FIXME:user@server_realm
The comment may not be clear for other people. I would be more verbose
about the FIXME.
+parts = user.split(@)
+if len(parts) 1:
+if parts[1].upper()==self.api.env.realm:
I don't think we wanted to do this hard-check of realm. Personally
I'am not against it because it's better to fail at login than at
subsequent command (which will happen). Anyway it should be commented.
+user=parts[0]
+else:
+return self.unauthorized(environ, start_response,
'', 'denied')
I expanded the comments, please check if you find them appropriate now.
Tomas
From e08691492241399bbe41802b945df0b714e16c00 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 15 Nov 2012 05:21:16 -0500
Subject: [PATCH] Add detection for users from trusted/invalid realms
When user from other realm than FreeIPA's tries to use Web UI
(login via forms-based auth or with valid trusted realm ticket),
the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied
is returned.
Also, the support for usernames of the form user@SERVER.REALM
or user@server.realm was added.
https://fedorahosted.org/freeipa/ticket/3252
---
ipaserver/plugins/ldap2.py | 2 ++
ipaserver/rpcserver.py | 20 +++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py
index bf1a0d3761b90cfa0784363aeaf40686e72c5d49..8e8e1604ff0a3d36fe3501ec6f54abdb717d78ae 100644
--- a/ipaserver/plugins/ldap2.py
+++ b/ipaserver/plugins/ldap2.py
@@ -727,6 +727,8 @@ class ldap2(CrudBackend):
except _ldap.SERVER_DOWN:
raise NetworkError(uri=self.ldap_uri,
error=u'LDAP Server Down')
+except _ldap.LOCAL_ERROR:
+raise errors.ACIError(info=info)
except _ldap.SUCCESS:
pass
except _ldap.LDAPError, e:
diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index 0856c25cef7904b3913b1666ddcf4965368f368a..d64e6514699c8679aa9e396c7b6b6256977a821f 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -809,7 +809,11 @@ class jsonserver_session(jsonserver, KerberosSession):
# Store the session data in the per-thread context
setattr(context, 'session_data', session_data)
-self.create_context(ccache=ipa_ccache_name)
+# This may fail if a ticket from wrong realm was handled via browser
+try:
+self.create_context(ccache=ipa_ccache_name)
+except ACIError, e:
+return self.unauthorized(environ, start_response, str(e), 'denied')
try:
response = super(jsonserver_session, self).__call__(environ, start_response)
@@ -927,6 +931,20 @@ class login_password(Backend, KerberosSession, HTTP_Status):
else:
return self.bad_request(environ, start_response, no user specified)
+# allows login in the form user@SERVER_REALM or user@server_realm
+# FIXME: uppercasing may be removed when better handling of UPN
+#is introduced
+parts = user.split(@)
+if len(parts) 1:
+# check whether the realm is server's realm
+# Users from other realms are not supported
+# (because they do not have necessary LDAP entry,
+# LDAP connect will fail)
+if parts[1].upper()==self.api.env.realm:
+user=parts[0]
+else:
+return self.unauthorized(environ, start_response, '', 'denied')
+
password = query_dict.get('password', None)
if password is not None:
if len(password) == 1:
--
1.7.11.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme
On 11/15/2012 01:09 PM, Petr Viktorin wrote: On 11/15/2012 12:04 PM, Martin Kosek wrote: On 11/15/2012 11:01 AM, Petr Viktorin wrote: On 11/14/2012 05:16 PM, Martin Kosek wrote: On 11/14/2012 05:05 PM, Martin Kosek wrote: On 11/14/2012 02:41 PM, Rob Crittenden wrote: Martin Kosek wrote: Remove redundant pki-* package Requires and change PKI server theme Requires to correct package name. https://fedorahosted.org/freeipa/ticket/3213 --- The patch fixes broken Requires with the new server theme package name (thanks Ade for help): # rpm -q pki-ca pki-ca-10.0.0-0.52.b3.fc18.noarch # rpm -qa *pki-*-theme dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch [root@vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* error: Failed dependencies: dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 This patch is intended for Fedora 18 only, of course. Martin ACK As discussed on IRC, I made the Requires conditional for Fedora 18 only so that we do not break environment for people still developing on Fedora 17 (like me). I also took the opportunity to do some clean ups of compatibility code for old Fedora 16 and older. Details are in the patch description. When/if this patch is accepted, Petr Viktorin's patch 0098 should go in too as we now require the affected pki-ca version on Fedora 18. Martin Since we are now touching tar, I also added it to BuildRequires. I think it bit me once when I built FreeIPA on some super-minimal Fedora compose. That should not be necessary, see https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 I assume the thing that bit you was grepping the .spec.in for the BuildRequires, but that shouldn't be a reason to change our spec. You are right, this is exactly what I did. Attaching a previous version of the patch, without BuildRequires tar. Martin Please also mention removing tomcat6 for F18+ in the %changelog and commit message. Then, it's an ACK. Fixed. Pushed to master, ipa-3-0 (with a small rebase). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0098 Provide explicit user name for Dogtag installation scripts
On 11/14/2012 09:43 AM, Petr Viktorin wrote: On 11/13/2012 11:23 PM, Rob Crittenden wrote: Petr Viktorin wrote: See commit message. Dogtag is changing its behavior soon (as in: tomorrow). This patch will be needed for IPA to install on Fedora 18. It would be nice if this went in our daily builds ASAP, so Dogtag people can test. Sorry for the short notice, I originally misunderstood Ade and included it in the merged database patches. I tested this with 3.0.1 in F-18 and it works as expected. I accidentally tested a mish-mash of this and saw how it would fail, so the patch is definitely needed. I've included the patch in the F-18 spec file only for now. Unless there is a need for us to push this upstream sooner. Do we also need to set the n-v-r of pki-core to the latest? This way, RPMs built straight from master won't work on F18, right? In older DT versions these are the defaults so having the patch in won't hurt. There's no need to change the spec for this patch. The spec problem Martin found is serious but unrelated. Pushed to master, ipa-3-0. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms
On Thu, 15 Nov 2012, Tomas Babej wrote: From e08691492241399bbe41802b945df0b714e16c00 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 15 Nov 2012 05:21:16 -0500 Subject: [PATCH] Add detection for users from trusted/invalid realms When user from other realm than FreeIPA's tries to use Web UI (login via forms-based auth or with valid trusted realm ticket), the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied is returned. Also, the support for usernames of the form user@SERVER.REALM or user@server.realm was added. https://fedorahosted.org/freeipa/ticket/3252 --- ipaserver/plugins/ldap2.py | 2 ++ ipaserver/rpcserver.py | 20 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py index bf1a0d3761b90cfa0784363aeaf40686e72c5d49..8e8e1604ff0a3d36fe3501ec6f54abdb717d78ae 100644 --- a/ipaserver/plugins/ldap2.py +++ b/ipaserver/plugins/ldap2.py @@ -727,6 +727,8 @@ class ldap2(CrudBackend): except _ldap.SERVER_DOWN: raise NetworkError(uri=self.ldap_uri, error=u'LDAP Server Down') +except _ldap.LOCAL_ERROR: +raise errors.ACIError(info=info) except _ldap.SUCCESS: pass except _ldap.LDAPError, e: diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py index 0856c25cef7904b3913b1666ddcf4965368f368a..d64e6514699c8679aa9e396c7b6b6256977a821f 100644 --- a/ipaserver/rpcserver.py +++ b/ipaserver/rpcserver.py @@ -809,7 +809,11 @@ class jsonserver_session(jsonserver, KerberosSession): # Store the session data in the per-thread context setattr(context, 'session_data', session_data) -self.create_context(ccache=ipa_ccache_name) +# This may fail if a ticket from wrong realm was handled via browser +try: +self.create_context(ccache=ipa_ccache_name) +except ACIError, e: +return self.unauthorized(environ, start_response, str(e), 'denied') try: response = super(jsonserver_session, self).__call__(environ, start_response) @@ -927,6 +931,20 @@ class login_password(Backend, KerberosSession, HTTP_Status): else: return self.bad_request(environ, start_response, no user specified) +# allows login in the form user@SERVER_REALM or user@server_realm +# FIXME: uppercasing may be removed when better handling of UPN +#is introduced +parts = user.split(@) +if len(parts) 1: +# check whether the realm is server's realm +# Users from other realms are not supported +# (because they do not have necessary LDAP entry, +# LDAP connect will fail) +if parts[1].upper()==self.api.env.realm: +user=parts[0] +else: +return self.unauthorized(environ, start_response, '', 'denied') + Can we also block NetBIOS\user logins? See ipaserver.dcerpc.DomainValidator's normalize_name() method, it handles both variants and returns a dict. You cannot use it unconditionally, though, since it is only available if freeipa-server-trust-ad package is installed. We can move this method to some common place since it does not require trusts per se and then re-use it in several places. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms
On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote: On 11/15/2012 11:54 AM, Tomas Babej wrote: Hi, This is server part of #3252. When user from other realm than FreeIPA's tries to use Web UI (login via forms-based auth or with valid trusted realm ticket), the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied is returned. Also, the support for usernames of the form user@SERVER.REALM or user@server.realm was added. https://fedorahosted.org/freeipa/ticket/3252 Tomas +# allows login in the form user@SERVER_REALM or FIXME:user@server_realm The comment may not be clear for other people. I would be more verbose about the FIXME. +parts = user.split(@) +if len(parts) 1: +if parts[1].upper()==self.api.env.realm: I don't think we wanted to do this hard-check of realm. Personally I'am not against it because it's better to fail at login than at subsequent command (which will happen). Anyway it should be commented. +user=parts[0] +else: +return self.unauthorized(environ, start_response, '', 'denied') I think you should really fail only if you get failure connecting to LDAP. Because we can easily allow logins by providing a mapping object as part of SASL rules, we simply do not do it yet. 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] [PATCH] IPA tool scripts
On 11/13/2012 09:50 AM, Martin Kosek wrote: On 11/10/2012 12:08 AM, Dmitri Pal wrote: On 11/09/2012 05:52 PM, Simo Sorce wrote: On Fri, 2012-11-09 at 15:59 -0500, Dmitri Pal wrote: On 11/09/2012 07:58 AM, Petr Vobornik wrote: On 11/09/2012 01:43 PM, Lynn Root wrote: The VERSION file and Makefile now handles 'beta' release parameters when making s/rpms. Ticket: https://fedorahosted.org/freeipa/ticket/2893 Lynn Root Associate Software Engineer Red Hat Thanks for the patch. In a next patch, I'd suggest to follow patch-naming conventions https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the patch number into a mail subject, it helps to keeping track of patches. OK, finally. It is a good time to ask. Several years ago when we adopted this format I was wondering what is the exact sequence of operations one should do to make the resulting patch follow the format. I never figured it out so I never adopted the format for the patches I provide for ding-libs from time to time. So in the title of the commit message I put (for example): [INI] Remove code that allows dup sections the I do git format-patch with arguments this translates into a patch with name 0001-INI-Remove-code-that-allows-dup-sections.patch So am I supposed to the manually rename the patch to follow the format or have a script to do that or there is some other way that I do not know about that would allow me to provide patches following the format above right out of the git format-patch so that I do not need to do the renaming? This patch format rule is followed only on freeipa-devel for Freeipa patches. Some people have developed scripts to do the renaming automatically. ding libs stuff is tracked on sssd-devel which does not use this patch format rule, we enver felt it necessary in sssd development. Simo. I understand. It was more a conceptual question. It looks like the answer there are scripts to do renaming that each developer has. Thanks. This is all I was looking for. Right. I understand that it may be difficult to follow the patch naming rule for new people in the project. But I personally like both numbering and naming conventions as it helps me with locating patches when reviewing and with referencing patch numbers in IRC conversations. The script is the most straightforward approach to choose For example when I am submitting a patch, all I need to do is to run a script which will extract the patch from git, name and number it correctly and opens me a Compose Email window in my MUA with patch already attached and description taken from the patch description. It can even upload the patch to Trac Ticket and switch patch sent for review to 1. If people are interested in the script, I can upload it to some github repo and we can link it then from our freeipa.org Contribute page. Martin I managed to upload few scripts relevant to submitting patches to FreeIPA to github: https://github.com/mkosek/ipa-tools ... and added a link to this git tree also to relevant section in Contribute page on freeipa.org in case that anybody finds it useful. I plan to polish it a bit when I have some free time as it still has many rough edges. But so far, the script(s) served me well for almost 2 years now :-) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA
Recently, the specfile changed (dce53e4) and the patch for changed
Dogtag defaults made it to master independently (91e477b). Attaching
rebased patch.
Note that to continue development on f17, you will need to use the
dogtag-devel repo:
sudo yum-config-manager
--add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo
On 11/13/2012 03:57 PM, Petr Viktorin wrote:
[...]
For convenience, I've also pushed the changes to a personal repository.
To fetch to branch pviktori-dogtag-10 you can do:
git fetch -f git://github.com/encukou/freeipa.git
dogtag-10:pviktori-dogtag-10
--
Petr³
From f92c5a4e07a464b28fda7f159ec20afcf45e191d Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Wed, 19 Sep 2012 23:35:42 -0400
Subject: [PATCH] Changes to use a single database for dogtag and IPA
New servers that are installed with dogtag 10 instances will use
a single database instance for dogtag and IPA, albeit with different
suffixes. Dogtag will communicate with the instance through a
database user with permissions to modify the dogtag suffix only.
This user will authenticate using client auth using the subsystem cert
for the instance.
This patch includes changes to allow the creation of masters and clones
with single ds instances.
---
freeipa.spec.in |9 ---
install/share/certmap.conf.template | 19 ---
install/tools/ipa-ca-install| 23 ++-
install/tools/ipa-csreplica-manage |2 +-
install/tools/ipa-replica-conncheck | 21 +++
install/tools/ipa-replica-install | 29 +++--
install/tools/ipa-replica-prepare |8 ++-
install/tools/ipa-server-install| 91 +-
install/tools/ipactl|6 ++-
ipapython/dogtag.py | 12 -
ipaserver/install/cainstance.py | 105 +-
ipaserver/install/dsinstance.py | 14 +++-
ipaserver/install/installutils.py |7 ++-
ipaserver/install/replication.py| 18 +++---
14 files changed, 250 insertions(+), 114 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 3ab0e3d4019ecfdda8ebb03415ff850167f5dfc3..d4f41ddea6c76e6a51a5f86274a0324f520ce615 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -114,17 +114,8 @@ Requires(post): systemd-units
Requires: selinux-policy = 3.10.0-110
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.40
-%if 0%{?fedora} = 18
Requires: pki-ca = 10.0.0-0.52.b3
Requires: dogtag-pki-server-theme
-%else
-Requires: pki-ca = 9.0.18
-Requires: pki-silent = 9.0.18
-Requires: pki-setup = 9.0.18
-Requires: dogtag-pki-common-theme
-Requires: dogtag-pki-ca-theme
-Requires: tomcat6 = 6.0.32-17
-%endif
%if 0%{?rhel}
Requires: subscription-manager
%endif
diff --git a/install/share/certmap.conf.template b/install/share/certmap.conf.template
index 676d3ef354c9dae4dce8c4682176e656088991b2..40b4e6cb1513bed586248e0c214730861b9715cf 100644
--- a/install/share/certmap.conf.template
+++ b/install/share/certmap.conf.template
@@ -71,12 +71,15 @@
# attr names- a comma separated list of attributes to form the filter
#
-certmap default default
+certmap default default
#default:DNComps
-#default:FilterComps e, uid
-#default:verifycert on
-#default:CmapLdapAttr certSubjectDN
-#default:library path_to_shared_lib_or_dll
-#default:InitFn Init function's name
-default:DNComps
-default:FilterComps uid
+#default:FilterCompse, uid
+#default:verifycert on
+#default:CmapLdapAttr certSubjectDN
+#default:librarypath_to_shared_lib_or_dll
+#default:InitFn Init function's name
+default:DNComps
+default:FilterComps uid
+certmap ipaca CN=Certificate Authority,O=domain_name
+ipaca:CmapLdapAttr seeAlso
+ipaca:verifycerton
diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index 1c1b96a91fbbef455a68b158cc0191b91f2232f9..df3aebc111069d2d164fee6336182089c09a7195 100755
--- a/install/tools/ipa-ca-install
+++ b/install/tools/ipa-ca-install
@@ -142,17 +142,32 @@ def main():
config.dir = dir
config.setup_ca = True
+portfile = config.dir + /dogtag_directory_port.txt
+if not ipautil.file_exists(portfile):
+dogtag_master_ds_port = 7389
+else:
+with open(portfile) as fd:
+dogtag_master_ds_port = fd.read()
+
if not options.skip_conncheck:
-replica_conn_check(config.master_host_name, config.host_name, config.realm_name, True, options.admin_password)
+replica_conn_check(
+config.master_host_name, config.host_name, config.realm_name, True,
+dogtag_master_ds_port, options.admin_password)
# Configure the CA if necessary
-(CA, cs) = cainstance.install_replica_ca(config, postinstall=True)
+(CA, cs) = cainstance.install_replica_ca(
+config, dogtag_master_ds_port, postinstall=True)
# We need to ldap_enable the CA now that DS is up and running
Re: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting timedate services
On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: Fedora 16 introduced chrony as default client timedate synchronization service: http://fedoraproject.org/wiki/Features/ChronyDefaultNTP Thus, there may be people already using chrony as their time and date synchronization service before installing IPA. However, installing IPA server or client on such machine may lead to unexpected behavior, as the IPA installer would configure ntpd and leave the machine with both ntpd and chronyd enabled. However, since the OS does not allow both chronyd and ntpd to be running concurrently and chronyd has the precedence, ntpd would not be run on that system at all. Make sure, that user is warned when trying to install IPA on such system and is given a possibility to either not to let IPA configure ntpd at all or to let the installer stop and disable chronyd. https://fedorahosted.org/freeipa/ticket/2974 This looks a bit backwards to me. The IPA server can only configure ntpd because it configures it to serve time to the clients. So on a server force_ntpd should be the default and the install should automatically shutdown crony. On clients we may give a choice, but then we should not stop, we should instead configure the one tool the admin wants to use and point it to the server, because time synchronization is critical. Not syncing time is basically not an option so our default behavior must be to make sure one of the time tool is properly configured and require a force flag if the admin wants to 'not' configure a time sync tool. 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] [PATCH 0023] Add detection for users from trusted/invalid realms
On 11/15/2012 03:10 PM, Simo Sorce wrote: On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote: On 11/15/2012 11:54 AM, Tomas Babej wrote: Hi, This is server part of #3252. When user from other realm than FreeIPA's tries to use Web UI (login via forms-based auth or with valid trusted realm ticket), the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied is returned. Also, the support for usernames of the form user@SERVER.REALM or user@server.realm was added. https://fedorahosted.org/freeipa/ticket/3252 Tomas +# allows login in the form user@SERVER_REALM or FIXME:user@server_realm The comment may not be clear for other people. I would be more verbose about the FIXME. +parts = user.split(@) +if len(parts) 1: +if parts[1].upper()==self.api.env.realm: I don't think we wanted to do this hard-check of realm. Personally I'am not against it because it's better to fail at login than at subsequent command (which will happen). Anyway it should be commented. +user=parts[0] +else: +return self.unauthorized(environ, start_response, '', 'denied') I think you should really fail only if you get failure connecting to LDAP. Because we can easily allow logins by providing a mapping object as part of SASL rules, we simply do not do it yet. Simo. Turns out if user from trusted realm logs in using WebUI form, he sucessfully obtaines ticket, however, a ccache is created with negative expiration time, because KRB5_CCache classes uses server's realm in its methods. Tomas realm ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms
On Thu, 2012-11-15 at 15:51 +0100, Tomas Babej wrote: On 11/15/2012 03:10 PM, Simo Sorce wrote: On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote: On 11/15/2012 11:54 AM, Tomas Babej wrote: Hi, This is server part of #3252. When user from other realm than FreeIPA's tries to use Web UI (login via forms-based auth or with valid trusted realm ticket), the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied is returned. Also, the support for usernames of the form user@SERVER.REALM or user@server.realm was added. https://fedorahosted.org/freeipa/ticket/3252 Tomas +# allows login in the form user@SERVER_REALM or FIXME:user@server_realm The comment may not be clear for other people. I would be more verbose about the FIXME. +parts = user.split(@) +if len(parts) 1: +if parts[1].upper()==self.api.env.realm: I don't think we wanted to do this hard-check of realm. Personally I'am not against it because it's better to fail at login than at subsequent command (which will happen). Anyway it should be commented. +user=parts[0] +else: +return self.unauthorized(environ, start_response, '', 'denied') I think you should really fail only if you get failure connecting to LDAP. Because we can easily allow logins by providing a mapping object as part of SASL rules, we simply do not do it yet. Simo. Turns out if user from trusted realm logs in using WebUI form, he sucessfully obtaines ticket, however, a ccache is created with negative expiration time, because KRB5_CCache classes uses server's realm in its methods. Uh odd. Well if the problem is deep there, then please open a ticket to fix that probelm and let's move on with your current solution. But we need either a ticket or a note somewhere (or maybe even just FIXMEs in your code comments) to make sure we improve this code later to check via LDAP so we do not hit a wall if/when we decide to allow trusted users to log into the ui. 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] cert-find design
On Thu, 2012-11-15 at 09:54 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2012-11-14 at 17:36 -0500, Rob Crittenden wrote: There is currently no way to search for a certificate. You can only look it up if you already know the serial number. Dogtag 10 has a fresh API which makes searching very easy. I've started designing a search interface here: http://freeipa.org/page/Cert_find Comments welcome. CAn you move it under V3/ that's where we agreed to put new designs for the v3 series Fixed. I was able to create a proof-of-concept (minus date options) using this API in about 90 minutes. Great! Question, how is authentication done ? Or is this all public information that can be freely obtained anonymously ? Or will we provide access control in the IPA API and let the dogtag REST interface be available only on localhost ? IMHO issued certificates are public, no point in adding a role/permissions to protect the search of them. Well I bet some people will want that anyway :-) But we can defer closing down till we get RFEs for that. The dogtag port is 8080 for this which I believe one doesn't need to open in the firewall, so only authenticated IPA users would have access. ok, good to know 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] cert-find design
On Thu, 2012-11-15 at 09:54 -0500, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2012-11-14 at 17:36 -0500, Rob Crittenden wrote: There is currently no way to search for a certificate. You can only look it up if you already know the serial number. Dogtag 10 has a fresh API which makes searching very easy. I've started designing a search interface here: http://freeipa.org/page/Cert_find Comments welcome. CAn you move it under V3/ that's where we agreed to put new designs for the v3 series Fixed. Thanks I removed the redirect too. The new link is: http://freeipa.org/page/V3/Cert_find 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] [PATCHES] Re: Changes to use a single database for dogtag and IPA
On 11/15/2012 03:19 PM, Petr Viktorin wrote: Recently, the specfile changed (dce53e4) and the patch for changed Dogtag defaults made it to master independently (91e477b). Attaching rebased patch. Note that to continue development on f17, you will need to use the dogtag-devel repo: sudo yum-config-manager --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo On 11/13/2012 03:57 PM, Petr Viktorin wrote: [...] For convenience, I've also pushed the changes to a personal repository. To fetch to branch pviktori-dogtag-10 you can do: git fetch -f git://github.com/encukou/freeipa.git dogtag-10:pviktori-dogtag-10 I started reviewing the patches, and found the first thing that looks suspicious. I had IPA with 2 databases, then upgraded it to single-database IPA, the upgrade was OK. But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed because when I installed single-db IPA afterwards, I had 2 dirsrv instances running. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting timedate services
On 11/15/2012 03:22 PM, Simo Sorce wrote: On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: Fedora 16 introduced chrony as default client timedate synchronization service: http://fedoraproject.org/wiki/Features/ChronyDefaultNTP Thus, there may be people already using chrony as their time and date synchronization service before installing IPA. However, installing IPA server or client on such machine may lead to unexpected behavior, as the IPA installer would configure ntpd and leave the machine with both ntpd and chronyd enabled. However, since the OS does not allow both chronyd and ntpd to be running concurrently and chronyd has the precedence, ntpd would not be run on that system at all. Make sure, that user is warned when trying to install IPA on such system and is given a possibility to either not to let IPA configure ntpd at all or to let the installer stop and disable chronyd. https://fedorahosted.org/freeipa/ticket/2974 This looks a bit backwards to me. The IPA server can only configure ntpd because it configures it to serve time to the clients. So on a server force_ntpd should be the default and the install should automatically shutdown crony. I considered that option too, but it simply just did not seem very polite to silently stop and disable chrony with some custom user timedate synchronization configuration that user may rely on. Telling user what's the problem and providing him with options what to do seemed more user friendly to me... On clients we may give a choice, but then we should not stop, we should instead configure the one tool the admin wants to use and point it to the server, because time synchronization is critical. Not syncing time is basically not an option so our default behavior must be to make sure one of the time tool is properly configured and require a force flag if the admin wants to 'not' configure a time sync tool. Simo. The force flag to not configure time sync tool is already there as --no-ntp. I already discussed this with Rob before, I was advised to rather stick with the ntpd only for the time being. Adding Rob to CC to comment on this one. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting timedate services
On 11/15/2012 05:33 PM, Martin Kosek wrote: On 11/15/2012 03:22 PM, Simo Sorce wrote: On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: Fedora 16 introduced chrony as default client timedate synchronization service: http://fedoraproject.org/wiki/Features/ChronyDefaultNTP Thus, there may be people already using chrony as their time and date synchronization service before installing IPA. However, installing IPA server or client on such machine may lead to unexpected behavior, as the IPA installer would configure ntpd and leave the machine with both ntpd and chronyd enabled. However, since the OS does not allow both chronyd and ntpd to be running concurrently and chronyd has the precedence, ntpd would not be run on that system at all. Make sure, that user is warned when trying to install IPA on such system and is given a possibility to either not to let IPA configure ntpd at all or to let the installer stop and disable chronyd. https://fedorahosted.org/freeipa/ticket/2974 This looks a bit backwards to me. The IPA server can only configure ntpd because it configures it to serve time to the clients. So on a server force_ntpd should be the default and the install should automatically shutdown crony. I considered that option too, but it simply just did not seem very polite to silently stop and disable chrony with some custom user timedate synchronization configuration that user may rely on. Telling user what's the problem and providing him with options what to do seemed more user friendly to me... +1 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA
On 11/15/2012 05:09 PM, Martin Kosek wrote: On 11/15/2012 03:19 PM, Petr Viktorin wrote: Recently, the specfile changed (dce53e4) and the patch for changed Dogtag defaults made it to master independently (91e477b). Attaching rebased patch. Note that to continue development on f17, you will need to use the dogtag-devel repo: sudo yum-config-manager --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo On 11/13/2012 03:57 PM, Petr Viktorin wrote: [...] For convenience, I've also pushed the changes to a personal repository. To fetch to branch pviktori-dogtag-10 you can do: git fetch -f git://github.com/encukou/freeipa.git dogtag-10:pviktori-dogtag-10 I started reviewing the patches, and found the first thing that looks suspicious. I had IPA with 2 databases, then upgraded it to single-database IPA, the upgrade was OK. But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed because when I installed single-db IPA afterwards, I had 2 dirsrv instances running. You're right. This is an uninstaller error already present in 2.2: https://fedorahosted.org/freeipa/ticket/3258 I'll start looking into it tomorrow, if nothing more important shows up. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms
On 11/15/2012 04:14 PM, Simo Sorce wrote:
On Thu, 2012-11-15 at 15:51 +0100, Tomas Babej wrote:
On 11/15/2012 03:10 PM, Simo Sorce wrote:
On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote:
On 11/15/2012 11:54 AM, Tomas Babej wrote:
Hi,
This is server part of #3252.
When user from other realm than FreeIPA's tries to use Web UI
(login via forms-based auth or with valid trusted realm ticket),
the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied
is returned.
Also, the support for usernames of the form user@SERVER.REALM
or user@server.realm was added.
https://fedorahosted.org/freeipa/ticket/3252
Tomas
+# allows login in the form user@SERVER_REALM or FIXME:user@server_realm
The comment may not be clear for other people. I would be more verbose
about the FIXME.
+parts = user.split(@)
+if len(parts) 1:
+if parts[1].upper()==self.api.env.realm:
I don't think we wanted to do this hard-check of realm. Personally I'am
not against it because it's better to fail at login than at subsequent
command (which will happen). Anyway it should be commented.
+user=parts[0]
+else:
+return self.unauthorized(environ, start_response, '', 'denied')
I think you should really fail only if you get failure connecting to
LDAP. Because we can easily allow logins by providing a mapping object
as part of SASL rules, we simply do not do it yet.
Simo.
Turns out if user from trusted realm logs in using WebUI form,
he sucessfully obtaines ticket, however, a ccache is created with
negative expiration time, because KRB5_CCache classes
uses server's realm in its methods.
Uh odd.
Well if the problem is deep there, then please open a ticket to fix that
probelm and let's move on with your current solution.
But we need either a ticket or a note somewhere (or maybe even just
FIXMEs in your code comments) to make sure we improve this code later to
check via LDAP so we do not hit a wall if/when we decide to allow
trusted users to log into the ui.
Simo.
The updated patch is attached. Please check if there are any other issues.
I will open the tickets after further investigation.
Tomas
From 51d2e1e4cee203bac70f21b3b2797e64e9d1277b Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 15 Nov 2012 05:21:16 -0500
Subject: [PATCH] Add detection for users from trusted/invalid realms
When user from other realm than FreeIPA's tries to use Web UI
(login via forms-based auth or with valid trusted realm ticket),
the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied
is returned.
Also, the support for usernames of the form user@SERVER.REALM
or user@server.realm was added.
https://fedorahosted.org/freeipa/ticket/3252
---
ipalib/util.py | 15 +++
ipaserver/dcerpc.py| 19 +++
ipaserver/plugins/ldap2.py | 2 ++
ipaserver/rpcserver.py | 37 +++--
4 files changed, 55 insertions(+), 18 deletions(-)
diff --git a/ipalib/util.py b/ipalib/util.py
index 3fe5c9f446ed2c5cdc5df2cb7b629fae8b319a4b..c52d060b55b51c9dbe2791bf92f8f002be9af9da 100644
--- a/ipalib/util.py
+++ b/ipalib/util.py
@@ -105,6 +105,21 @@ def validate_host_dns(log, fqdn):
)
raise errors.DNSNotARecordError()
+def normalize_name(name):
+result = dict()
+components = name.split('@')
+if len(components) == 2:
+result['domain'] = unicode(components[1]).lower()
+result['name'] = unicode(components[0]).lower()
+else:
+components = name.split('\\')
+if len(components) == 2:
+result['flatname'] = unicode(components[0]).lower()
+result['name'] = unicode(components[1]).lower()
+else:
+result['name'] = unicode(name).lower()
+return result
+
def isvalid_base64(data):
Validate the incoming data as valid base64 data or not.
diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index 4eddbcdc304de9e50c5ccb9a71808fb71cf5b844..4e83926dbcf2bd3f64c9e358e00c59c5aa603c91 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -31,6 +31,7 @@ from ipapython import ipautil
from ipapython.ipa_log_manager import *
from ipapython.dn import DN
from ipaserver.install import installutils
+from ipalib.util import normalize_name
import os, string, struct, copy
import uuid
@@ -184,21 +185,6 @@ class DomainValidator(object):
return True
return False
-def normalize_name(self, name):
-result = dict()
-components = name.split('@')
-if len(components) == 2:
-result['domain'] = unicode(components[1]).lower()
-result['name'] = unicode(components[0]).lower()
-else:
-components = name.split('\\')
-if len(components) == 2:
-result['flatname'] = unicode(components[0]).lower()
-result['name'] = unicode(components[1]).lower()
-else:
-
Re: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting timedate services
On Thu, 2012-11-15 at 17:33 +0100, Martin Kosek wrote: On 11/15/2012 03:22 PM, Simo Sorce wrote: On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: Fedora 16 introduced chrony as default client timedate synchronization service: http://fedoraproject.org/wiki/Features/ChronyDefaultNTP Thus, there may be people already using chrony as their time and date synchronization service before installing IPA. However, installing IPA server or client on such machine may lead to unexpected behavior, as the IPA installer would configure ntpd and leave the machine with both ntpd and chronyd enabled. However, since the OS does not allow both chronyd and ntpd to be running concurrently and chronyd has the precedence, ntpd would not be run on that system at all. Make sure, that user is warned when trying to install IPA on such system and is given a possibility to either not to let IPA configure ntpd at all or to let the installer stop and disable chronyd. https://fedorahosted.org/freeipa/ticket/2974 This looks a bit backwards to me. The IPA server can only configure ntpd because it configures it to serve time to the clients. So on a server force_ntpd should be the default and the install should automatically shutdown crony. I considered that option too, but it simply just did not seem very polite to silently stop and disable chrony with some custom user timedate synchronization configuration that user may rely on. Telling user what's the problem and providing him with options what to do seemed more user friendly to me... not on the server, no you don;t get to choose there, unless you call install script with --no-ntp On clients we may give a choice, but then we should not stop, we should instead configure the one tool the admin wants to use and point it to the server, because time synchronization is critical. Not syncing time is basically not an option so our default behavior must be to make sure one of the time tool is properly configured and require a force flag if the admin wants to 'not' configure a time sync tool. Simo. The force flag to not configure time sync tool is already there as --no-ntp. I already discussed this with Rob before, I was advised to rather stick with the ntpd only for the time being. Adding Rob to CC to comment on this one. Not sure I grok what this entails, support only ntpd ? In this case we can error out if crony is there on the client, but not on the server. On the server we just roll over crony, as crony is not an ntp server at all so it should go if the admin *really*insist in using crony then they'll have to explicitly install the server with --no-ntp note that we are not going to change crony;s configuration just turn it off and start ntpd instead. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 1072 enable transaction support
This patch enables transaction support in 389-ds-base and fixes a few
transaction issues within IPA.
This converts parts of the password and modrnd plugins to support
transactions. The password plugin still largely runs as
non-transactional because extop plugins aren't supported in transactions
yet.
I've left the wait_for_attr code in place for now but on reflection we
should probably remove it. I'll leave that up to the reviewer, but I
can't see the need for it any more.
In order for this to work you'll need to apply the last two patches
(both 0001) to slapi-nis and spin it up yourself, otherwise you'll have
serious deadlock issues. I know this is extra work but this patch is
potentially disruptive so I figure the earlier it is out the better.
Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may have
been too aggressive in my cleanup.
Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch?
Once we have an official slapi-nis build with these patches we'll need
to set the minimum n-v-r in our spec file.
rob
From aaeb6c0efd0289ca17731ab8cc8e62e39e8b1c5d Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 15 Nov 2012 21:38:26 -0500
Subject: [PATCH] Enable transactions by default, make password and modrdn
TXN-aware
The password and modrdn plugins needed to be made transaction aware
for the pre and post operations.
Remove the reverse member hoop jumping. Just fetch the entry once
and all the memberof data is there (plus objectclass).
Fix some unit tests that are failing because we actually get the data
now due to transactions.
Add small bit of code in user plugin to retrieve the user again
ala wait_for_attr but in the case of transactions we need do it only
once.
https://fedorahosted.org/freeipa/ticket/1263
https://fedorahosted.org/freeipa/ticket/1891
https://fedorahosted.org/freeipa/ticket/2056
https://fedorahosted.org/freeipa/ticket/3043
https://fedorahosted.org/freeipa/ticket/3191
https://fedorahosted.org/freeipa/ticket/3046
---
daemons/ipa-slapi-plugins/ipa-modrdn/ipa_modrdn.c | 26 --
.../ipa-slapi-plugins/ipa-modrdn/modrdn-conf.ldif | 2 +-
.../ipa-pwd-extop/ipa_pwd_extop.c | 21
daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h | 2 +
.../ipa-pwd-extop/ipapwd_prepost.c | 24 +
.../ipa-pwd-extop/pwd-extop-conf.ldif | 1 +
install/share/nis.uldif| 1 +
install/share/schema_compat.uldif | 1 +
install/updates/10-disable-betxn.update| 37 -
install/updates/10-enable-betxn.update | 43
install/updates/Makefile.am| 2 +-
ipalib/plugins/baseldap.py | 60 +++---
ipalib/plugins/user.py | 5 ++
ipaserver/install/dsinstance.py| 4 --
tests/test_xmlrpc/test_automember_plugin.py| 10
tests/test_xmlrpc/test_nesting.py | 1 +
tests/test_xmlrpc/test_permission_plugin.py| 2 +-
tests/test_xmlrpc/test_privilege_plugin.py | 7 +++
tests/test_xmlrpc/test_role_plugin.py | 5 ++
19 files changed, 152 insertions(+), 102 deletions(-)
delete mode 100644 install/updates/10-disable-betxn.update
create mode 100644 install/updates/10-enable-betxn.update
diff --git a/daemons/ipa-slapi-plugins/ipa-modrdn/ipa_modrdn.c b/daemons/ipa-slapi-plugins/ipa-modrdn/ipa_modrdn.c
index 70a4ea82144829015e663c37212af7196a9ad72a..6cec5f242b7d23d3752e5bc30c67e034abc96abb 100644
--- a/daemons/ipa-slapi-plugins/ipa-modrdn/ipa_modrdn.c
+++ b/daemons/ipa-slapi-plugins/ipa-modrdn/ipa_modrdn.c
@@ -201,6 +201,12 @@ ipamodrdn_init(Slapi_PBlock *pb)
{
int status = EOK;
char *plugin_identity = NULL;
+Slapi_Entry *plugin_entry = NULL;
+char *plugin_type = NULL;
+int delfn = SLAPI_PLUGIN_POST_DELETE_FN;
+int mdnfn = SLAPI_PLUGIN_POST_MODRDN_FN;
+int modfn = SLAPI_PLUGIN_POST_MODIFY_FN;
+int addfn = SLAPI_PLUGIN_POST_ADD_FN;
LOG_TRACE(--in--\n);
@@ -213,6 +219,18 @@ ipamodrdn_init(Slapi_PBlock *pb)
PR_ASSERT(plugin_identity);
setPluginID(plugin_identity);
+if ((slapi_pblock_get(pb, SLAPI_PLUGIN_CONFIG_ENTRY, plugin_entry) == 0)
+plugin_entry
+(plugin_type = slapi_entry_attr_get_charptr(plugin_entry, nsslapd-plugintype))
+plugin_type strstr(plugin_type, betxn))
+{
+addfn = SLAPI_PLUGIN_BE_TXN_POST_ADD_FN;
+mdnfn = SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN;
+delfn = SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN;
+modfn = SLAPI_PLUGIN_BE_TXN_POST_MODIFY_FN;
+}
+slapi_ch_free_string(plugin_type);
+
if (slapi_pblock_set(pb, SLAPI_PLUGIN_VERSION,
SLAPI_PLUGIN_VERSION_01) != 0 ||
slapi_pblock_set(pb, SLAPI_PLUGIN_DESCRIPTION,
@@ -221,13 +239,13 @@ ipamodrdn_init(Slapi_PBlock *pb)
