Re: [Freeipa-devel] certprofiles -- problem with delete

[Fraser Tweedale]

On Thu, May 21, 2015 at 03:20:30PM +0200, Martin Kosek wrote:
> On 05/21/2015 03:10 PM, Fraser Tweedale wrote:
> > On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote:
> >> Hi Fraser and list,
> >>
> >> I ran into this when I was tinkering with the commands.
> >>
> >> The ipa certprofile plugin[s] does not take the backend result into the
> >> picture right now. When I tried to delete the *default profile*, the entry
> >> from ipa suffix got deleted. However the command failed
> >> and the profile is still in the dogtag managed suffix.
> >> After I've done this to the installed instance, subsequent uninstall
> >> operation failed on some step involving dogtag. I suspect it is related.
> >> I haven't been able to reproduce this for now as at the moment there
> >> was no package with dogtag in the copr repo.
> >> Reproducer for this is attached. (This reproducer requires patches at
> >> least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch)
> >>
> >> It may be more complicated issue than it seems, though.
> >> If we delete the ipa managed entry before the dogtag operation
> >> and this one fails, it leaves us in an inconsistent state.
> >> If on the other hand we delete the ipa managed entry after dogtag
> >> call, it opens an possibility of failing to delete the entry in ipa, 
> >> leading
> >> to inconsistency again.
> >>
> >> The solution to this would be a transaction. The problem here is
> >> that the transaction here would span through two integrated
> >> components (three actually, ipa, 389 and dogtag, in this context).
> >> Not an easy thing to do I assume.
> >>
> >> TL;DR:
> >>
> >>  * certprofile-del deletes ipa managed entry and dogtag doesn't
> >>  * how do we approach possibly irreversible changes in LDAPObject
> >> plugins when integrated component doesn't behave?
> >>
> >> Your thoughts on this?
> >>
> > Thanks for the report - certprofile-del was working at an earlier
> > stage so I will track down the issue and fix.
> > 
> > I have pondered the transaction requirements: I am managing it for
> > certprofile-import by deleting the entry if the dogtag import fails.
> > I suppose I can do a similar thing for certprofile del - keep a copy
> > of the entry and re-add it if delete fails.  Sound OK to you?
> 
> Yeah, this is what we do in permission-mod post_callback for example.
> 
> > 
> > Cheers,
> > Fraser
> > 
> >>
> >> Thanks,
> >> Milan
> > 
> > 
> 
Milan, I found the problem and it is fixed in the next patch set.

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management

[Fraser Tweedale]

On Thu, May 21, 2015 at 05:33:11PM +0200, Martin Basti wrote:
> On 20/05/15 16:41, Fraser Tweedale wrote:
> >Hi Honza, Martin et al,
> >
> >Latest patches attached.  On top of previous patches (most review
> >matters addressed**) patches 0008..0011 add support for profiles and
> >user certificates to `ipa cert-request'.
> >
> >** those that were not are being tracked at [1]; please add anything
> >I missed.
> >
> >Some points to note:
> >
> >- usercertificate is not yet a multi-valued attribute for users,
> >   hosts and services.
> >
> >   QUESTION - we do want to allow multiple certificates for all
> >   principal types, not just users?  Or have I got that wrong.
> Changing schema can cause issues in future, we already burn ourselves
> several times.
> If you plan to have multi valued attribute in close future, could be better
> to have mutltivalued schema now, instead of make this change in future?
> 
The 'usercertificate' attribute is multi-valued in schema.  Only how
we treat it in IPA framework would change.

Martin Kosek clarified that services and hosts are also supporting
multiple certs so I will make that change for next patch set as
well.

> >
> >- "DN and SAN match principal" checks are not implemented for users
> >   yet.
> >
> >- ACL was added to allow user principals to request their own
> >   certificates, however, this will be further subject to CA/profile
> >   ACLs which are to come.
> >
> >- Pursuant to [2] revocation logic was removed from `cert-request'
> >
> >[1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress
> >[2] 
> >http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates
> >
> >Thanks,
> >Fraser
> Thanks for updated patches:
> 
> Please update required pki version in freeipa.spec.in
> 
> Patch 0001:
> Again, will be this change done after upgrade, instead of new installation?
> config.set("CA", "pki_profiles_in_ldap", "True")
> 
> I blame method 'ca_enable_ldap_profile_subsystem' in upgrade to do this, but
> I'm not sure.
> 
That's correct.  The `config.set' is setting the value in the
(ephemeral) pkispawn(8) config file.

> 
> Patch 0005:
> 1)
> just nitpick:
> profile_id_pattern = re.compile('^[a-zA-Z]\w*$')
> PROFILE_ID_PATTERN = re.compile('^profileId=(\w+)', re.MULTILINE)
> 
> In PROFILE_ID_PATTERN should be '^profileId=([a-zA-Z]\w*)' to be consistent
> 
Good point; is fixed for next patchset.

> Patch 0007:
> There are still modifications in ipa-server-isntall
> 
It is necessary to import the included profiles into Dogtag after
LDAP updates are applied to IPA DIT, so that step is inevitable.

I would like to avoid the import hackery but haven't found the
better way yet.  IMO it shouldn't be a blocker, but something to
revisit once I finish the caacl plugin and move to bugfixing /
polishing.  (I suspect the best way forward is to explicitly pass
more arguments around where they are needed and reduce the amount of
shared state that is implicitly relied on in the module.)

> Patch 0010:
> 1)
> +aci: (targetattr = "usercertificate")(version 3.0;acl "selfservice:Users
> can manage their own X.509 certificates";allow (write) userdn =
> "ldap:///self";;)
>  This is not in any upgrade file
> 
> 2)
> +# User certificates
> +dn: $SUFFIX
> +add:aci:(targetattr = "ipasshpubkey")(version 3.0;acl "selfservice:Users
> can manage their own X.509 certificates";allow (write) userdn =
> "ldap:///self";;)
> Is this right? (ipasshpubkey) This ACI with different name is already there.
> 
Whups, this is copy-pasta error :)  Changing it to 'usercertificate'
will fix 1) and 2).  This is done for the next patchset.

> 3)
> IMO this should not be there.
> 
>  'replaces': [
> -'(targetattr = "givenname || sn || cn || displayname ||
> title || initials || loginshell || gecos || homephone || mobile || pager ||
> facsimiletelephonenumber || telephonenumber || street || roomnumber || l ||
> st || postalcode || manager || secretary || description || carlicense ||
> labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory
> || ou || mepmanagedentry || objectclass")(target =
> "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX";)(version 3.0;acl
> "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify
> Users,cn=permissions,cn=pbac,$SUFFIX";)',
> +'(targetattr = "givenname || sn || cn || displayname ||
> title || initials || loginshell || gecos || homephone || mobile || pager ||
> facsimiletelephonenumber || telephonenumber || street || roomnumber || l ||
> st || postalcode || manager || secretary || description || carlicense ||
> labeleduri || inetuserhttpurl || seealso || employeetype || businesscategory
> || usercertificate || ou || mepmanagedentry || objectclass")(target =
> "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX";)(version 3.0;acl
> "permission:Modify Users";allow (write) groupdn = "ldap:///cn=Modify
> Users,cn=permissions,cn=pbac,$SUFFIX";)',
>  ],
> 
> this replace replace

[Freeipa-devel] [PATCH 0258] Server Upgrade: move code from ipa-upgrade config into separate module

[Martin Basti]

IPA services upgrade is executed only by ipa-server-upgrade, 
ipa-upgradeconfig will not work.


Patch attached.

https://fedorahosted.org/freeipa/ticket/4904

--
Martin Basti

From 23272ea2f1eb8473563a7c84bbae3f276a9a495f Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 22 May 2015 17:38:16 +0200
Subject: [PATCH] Server Upgrade: Move code from ipa-upgradeconfig to separate
 module

This also prevent the script ipa-upgradeconfig execute upgrading.
Upgrade of services is called from ipa-server-upgrade

https://fedorahosted.org/freeipa/ticket/4904
---
 install/tools/ipa-upgradeconfig| 1408 +---
 ipaserver/install/ipa_server_upgrade.py|   15 +-
 .../install/server.py  |   86 +-
 3 files changed, 33 insertions(+), 1476 deletions(-)
 copy install/tools/ipa-upgradeconfig => ipaserver/install/server.py (95%)
 mode change 100755 => 100644

diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index dfef1e0aa8b1507b7aa4907e9b688ce99253b87c..939bc349f4261ec3e5eedbfb1a1135fca8a17ea0 100755
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -24,1412 +24,8 @@ Upgrade configuration files to a newer template.
 """
 
 import sys
-import re
-import os
-import shutil
-import pwd
-import fileinput
-import ConfigParser
-import grp
 
-from ipalib import api
-import SSSDConfig
-import ipalib.util
-import ipalib.errors
-from ipaplatform import services
-from ipaplatform.tasks import tasks
-from ipapython import ipautil, sysrestore, version, certdb
-from ipapython.config import IPAOptionParser
-from ipapython.ipa_log_manager import *
-from ipapython import certmonger
-from ipapython import dogtag
-from ipaplatform.paths import paths
-from ipaserver.install import installutils
-from ipaserver.install import dsinstance
-from ipaserver.install import httpinstance
-from ipaserver.install import memcacheinstance
-from ipaserver.install import bindinstance
-from ipaserver.install import service
-from ipaserver.install import cainstance
-from ipaserver.install import certs
-from ipaserver.install import otpdinstance
-from ipaserver.install import sysupgrade
-from ipaserver.install import dnskeysyncinstance
-
-
-def parse_options():
-parser = IPAOptionParser(version=version.VERSION)
-parser.add_option("-d", "--debug", dest="debug", action="store_true",
-  default=False, help="print debugging information")
-parser.add_option("-q", "--quiet", dest="quiet",
-  action="store_true",
-  default=False, help="Output only errors")
-
-options, args = parser.parse_args()
-safe_options = parser.get_safe_opts(options)
-
-return safe_options, options
-
-class KpasswdInstance(service.SimpleServiceInstance):
-def __init__(self):
-service.SimpleServiceInstance.__init__(self, "ipa_kpasswd")
-
-def uninstall_ipa_kpasswd():
-"""
-We can't use the full service uninstaller because that will attempt
-to stop and disable the service which by now doesn't exist. We just
-want to clean up sysrestore.state to remove all references to
-ipa_kpasswd.
-"""
-ipa_kpasswd = KpasswdInstance()
-
-running = ipa_kpasswd.restore_state("running")
-enabled = not ipa_kpasswd.restore_state("enabled")
-
-if enabled is not None and not enabled:
-ipa_kpasswd.remove()
-
-def backup_file(filename, ext):
-"""Make a backup of filename using ext as the extension. Do not overwrite
-   previous backups."""
-if not os.path.isabs(filename):
-raise ValueError("Absolute path required")
-
-backupfile = filename + ".bak"
-(reldir, file) = os.path.split(filename)
-
-while os.path.exists(backupfile):
-backupfile = backupfile + "." + str(ext)
-
-try:
-shutil.copy2(filename, backupfile)
-except IOError, e:
-if e.errno == 2: # No such file or directory
-pass
-else:
-raise e
-
-def update_conf(sub_dict, filename, template_filename):
-template = ipautil.template_file(template_filename, sub_dict)
-fd = open(filename, "w")
-fd.write(template)
-fd.close()
-
-def find_hostname():
-"""Find the hostname currently configured in ipa-rewrite.conf"""
-filename=paths.HTTPD_IPA_REWRITE_CONF
-
-if not ipautil.file_exists(filename):
-return None
-
-pattern = "^[\s#]*.*https:\/\/([A-Za-z0-9\.\-]*)\/.*"
-p = re.compile(pattern)
-for line in fileinput.input(filename):
-if p.search(line):
-fileinput.close()
-return p.search(line).group(1)
-fileinput.close()
-
-raise RuntimeError("Unable to determine the fully qualified hostname from %s" % filename)
-
-def find_autoredirect(fqdn):
-"""
-When upgrading ipa-rewrite.conf we need to see if the automatic redirect
-was disabled during install time (or afterward). So sift through the
-configuration file and 

[Freeipa-devel] [PATCH 0257] ULC: Fix: Upgrade for stage user admins failed

[Martin Basti]

Patch attached.

--
Martin Basti

From b393e37d3e749f17d96e6d9272cc08dc9690e4ff Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 22 May 2015 17:43:54 +0200
Subject: [PATCH] ULC: fix: upgrade for stage Stage User Admins failed

Upgrade failed because entry 'dn: cn=Stage User
Administrators,cn=privileges,cn=pbac,$SUFFIX' doesnt exist.

Now upgrade will create the privilege if it does not exist.
---
 install/updates/45-roles.update | 5 +
 1 file changed, 5 insertions(+)

diff --git a/install/updates/45-roles.update b/install/updates/45-roles.update
index eb50e2b9c8c10b84dfc82782ea52f8a8534e862d..dd4549f3141113d559fa1ef994b0d5abab2aa197 100644
--- a/install/updates/45-roles.update
+++ b/install/updates/45-roles.update
@@ -29,6 +29,11 @@ dn: cn=Group Administrators,cn=privileges,cn=pbac,$SUFFIX
 add: member: cn=User Administrator,cn=roles,cn=accounts,$SUFFIX
 
 dn: cn=Stage User Administrators,cn=privileges,cn=pbac,$SUFFIX
+default:objectClass: groupofnames
+default:objectClass: nestedgroup
+default:objectClass: top
+default:cn: Stage User Administrators
+default:description: Stage User Administrators
 add: member: cn=User Administrator,cn=roles,cn=accounts,$SUFFIX
 
 dn: cn=IT Specialist,cn=roles,cn=accounts,$SUFFIX
-- 
2.1.0

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors

[Martin Basti]

On 22/05/15 17:40, Gabe Alford wrote:
On Fri, May 22, 2015 at 9:01 AM, Martin Basti > wrote:


On 22/05/15 16:08, Gabe Alford wrote:

Hello,

This should fix https://fedorahosted.org/freeipa/ticket/3584, and
as requested in the ticket, this should also fix
https://fedorahosted.org/freeipa/ticket/2284

Thanks,

Gabe



Thank you!

IMO your first part of fix only mask issue, not solving it.

This could be way, but I did not test it.

out_encoding = getattr(outfile, 'encoding', None)
if out_encoding is None:
out_encoding = 'utf-8'
print >> outfile, unicode(string).encode(out_encoding)


I'm confused and maybe missing something here. If I run `ipa help dns 
| bad_command`, shouldn't the command fail with only the following?

-bash: bad: command not found
Oh sorry, I misread the exception there, I did read unicode error, I 
dont know why.

You are right.



Can you split this patch into 2 separate patches for each ticket
please?


Done

Martin^2

-- 
Martin Basti






--
Martin Basti

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors

[Gabe Alford]

On Fri, May 22, 2015 at 9:01 AM, Martin Basti  wrote:

>  On 22/05/15 16:08, Gabe Alford wrote:
>
>  Hello,
>
>  This should fix https://fedorahosted.org/freeipa/ticket/3584, and as
> requested in the ticket, this should also fix
> https://fedorahosted.org/freeipa/ticket/2284
>
>  Thanks,
>
>  Gabe
>
>
>  Thank you!
>
> IMO your first part of fix only mask issue, not solving it.
>
> This could be way, but I did not test it.
>
> out_encoding = getattr(outfile, 'encoding', None)
> if out_encoding is None:
> out_encoding = 'utf-8'
> print >> outfile,  unicode(string).encode(out_encoding)
>

I'm confused and maybe missing something here. If I run `ipa help dns |
bad_command`, shouldn't the command fail with only the following?

-bash: bad: command not found



>
> Can you split this patch into 2 separate patches for each ticket please?
>

Done


> Martin^2
>
> --
> Martin Basti
>
>
From bea5786dbf6363c6bae541c347b3dd98d7dc23bd Mon Sep 17 00:00:00 2001
From: Gabe 
Date: Fri, 22 May 2015 09:19:03 -0600
Subject: [PATCH] Allow ipa help command to run when ipa-client-install is not
 configured

https://fedorahosted.org/freeipa/ticket/3584
---
 ipalib/cli.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipalib/cli.py b/ipalib/cli.py
index fc6e2303919d4db724d97f839d9a1b71752dfc10..398b5486339ad6930b7b11a53a2b7e6d90903371 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -1333,7 +1333,7 @@ def run(api):
 api.register(klass)
 api.load_plugins()
 api.finalize()
-if not 'config_loaded' in api.env:
+if not 'config_loaded' in api.env and not 'help' in argv:
 raise NotConfiguredError()
 sys.exit(api.Backend.cli.run(argv))
 except KeyboardInterrupt:
-- 
1.8.3.1

From 7b12c4a2818e776f48045eca51027fd5f6df6286 Mon Sep 17 00:00:00 2001
From: Gabe 
Date: Fri, 22 May 2015 09:25:08 -0600
Subject: [PATCH] Do not print traceback when pipe is broken

https://fedorahosted.org/freeipa/ticket/2284
---
 ipalib/cli.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ipalib/cli.py b/ipalib/cli.py
index 398b5486339ad6930b7b11a53a2b7e6d90903371..52529ea02c35a8119a5fb2397d7302d170e81526 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -799,7 +799,10 @@ class help(frontend.Local):
 
 def _writer(self, outfile):
 def writer(string=''):
-print >> outfile, unicode(string)
+try:
+print >> outfile, unicode(string)
+except IOError:
+pass
 return writer
 
 def print_topics(self, outfile):
-- 
1.8.3.1

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0048] fix ipa help command output errors

[Martin Basti]

On 22/05/15 16:08, Gabe Alford wrote:

Hello,

This should fix https://fedorahosted.org/freeipa/ticket/3584, and as 
requested in the ticket, this should also fix 
https://fedorahosted.org/freeipa/ticket/2284


Thanks,

Gabe



Thank you!

IMO your first part of fix only mask issue, not solving it.

This could be way, but I did not test it.

out_encoding = getattr(outfile, 'encoding', None)
if out_encoding is None:
out_encoding = 'utf-8'
print >> outfile, unicode(string).encode(out_encoding)

Can you split this patch into 2 separate patches for each ticket please?

Martin^2

--
Martin Basti

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature

[Tomas Babej]

On 05/22/2015 03:52 PM, Tomas Babej wrote:



On 05/22/2015 03:32 PM, Petr Vobornik wrote:

On 05/22/2015 03:18 PM, Petr Vobornik wrote:

On 05/22/2015 01:08 PM, Tomas Babej wrote:

snip



1) 
https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html

- I still don't agree that the plugin should be based on LDAPObject.


On the other hand, with LDAPObject base, Web UI for this feature is
much more simpler because it can rely on existing conventions.


IMHO we can swap the approach in a later patch, if we decide it's
necessary. It does not block or relate to other features much.





2) Use api domainlevel-show call to get the current domain level in
ipa-replica-install instead of duplicating the code.

I chose the former approach since the domainlevel_show command doesn't
need to be available, but yeah, this can be properly detected and 
worked

around too. Fixed.



3) Set the domain level in DSInstance.create_instance instead of a
separate call in ipa-server-install. It should be done about the 
same

time as the master entry is added.

4) I think the option should be named --domain-level (with a 
dash), for

consistency.





All other issues fixed.

Updated patch atttached


[36/41]: initializing domain level
   [error] TypeError: __set_domain_level() takes exactly 2 arguments (1
given)
Unexpected error - see /var/log/ipaserver-install.log for details:
TypeError: __set_domain_level() takes exactly 2 arguments (1 given)


Install failed



2. during installation, __set_domain_level is called before the 
Domain Level entry is created and hence it fails even if the issue 
above is fixed




Yeah.. we probably need to apply the 72-domainlevel.ldif manually.


Updated patch attached. I ran a successful installation with this patch.

Tomas
From dbea5027ae4fabb4b1149a09d28799bdb4de2eaa Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 14 May 2015 10:49:55 +0200
Subject: [PATCH] Add Domain Level feature

https://fedorahosted.org/freeipa/ticket/5018
---
 ACI.txt|   2 +
 API.txt|  22 ++
 install/share/72domainlevels.ldif  |   6 ++
 install/share/Makefile.am  |   2 +
 install/share/domainlevel.ldif |   7 ++
 install/tools/ipa-replica-install  |  34 +++-
 install/tools/ipa-server-install   |  22 +-
 install/updates/72-domainlevels.update |  14 
 install/updates/Makefile.am|   1 +
 ipalib/constants.py|   3 +
 ipalib/errors.py   |  16 
 ipalib/plugins/domainlevel.py  | 137 +
 ipaserver/install/dsinstance.py|  12 ++-
 ipaserver/install/ldapupdate.py|   5 ++
 14 files changed, 273 insertions(+), 10 deletions(-)
 create mode 100644 install/share/72domainlevels.ldif
 create mode 100644 install/share/domainlevel.ldif
 create mode 100644 install/updates/72-domainlevels.update
 create mode 100644 ipalib/plugins/domainlevel.py

diff --git a/ACI.txt b/ACI.txt
index bf539892910f14ebc3fbee88a72d2b57c0d1327b..d38d1c6f5e7f3095704e2c205a52316b4f39f469 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -50,6 +50,8 @@ dn: dc=ipa,dc=example
 aci: (target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Remove DNS Entries";allow (delete) groupdn = "ldap:///cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: dc=ipa,dc=example
 aci: (targetattr = "a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord")(target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Update DNS Entries";allow (write) groupdn = "ldap:///cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+dn: dc=ipa,dc=example
+aci: (targetattr = "createtimestamp || entryusn || ipadomainlevel || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipadomainlevelconfig)")(version 3.0;acl "permission:System: Read Domain Level";allow (compare,read,search) userdn = "ldap:///all";;)
 dn: cn=groups,cn=accounts,dc=ipa,dc=example
 aci: (targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Add Groups";allow (add) groupdn = "ldap:///cn=System: Add Groups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=groups,c

Re: [Freeipa-devel] [PATCH] manage replication topology in the shared tree

[Petr Vobornik]

On 05/21/2015 12:55 PM, thierry bordaz wrote:

On 05/20/2015 05:40 PM, Ludwig Krispenz wrote:

please find new versions of patches 0003 and 0005 for  the topology
plugin.

the ds plugin patch includes
- changes to match domain level patch
- remove trailing white spaces
- use proper oids for topology schema

the install patch
- has the  70topology.ldif removed


Hello Ludwig,

I failed to do 'git am patch-0003', it returned a strange "Patch format
detection failed.".
However I was able to do 'git apply' and to review it.

I focus on the points discussed during previous reviews.
The patch is looking good to me. ACK


Patch 0005 looks good to me if we squash there attached patch(typo fixes).

I think that both 0003 and 0005 could be pushed. But I'll do it when 
testing with Domain Level patch is successful.


patch 0006 will be replaced with the one I'm working on.



thanks
thierry



--
Petr Vobornik
From d83ae4ccf4d74f89e4a12fbeefc3d46abfdf3b61 Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Fri, 22 May 2015 13:40:25 +0200
Subject: [PATCH] topology installation - minor fixes

---
 install/share/topology-entries.ldif | 2 +-
 ipaserver/install/dsinstance.py | 2 +-
 ipaserver/install/replication.py| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/install/share/topology-entries.ldif b/install/share/topology-entries.ldif
index 309246f0b0d038741d8c44be6d96614c77095e83..5ee4f617a0e578382e895d9f9ca0d4079af80741 100644
--- a/install/share/topology-entries.ldif
+++ b/install/share/topology-entries.ldif
@@ -4,7 +4,7 @@ objectclass: top
 objectclass: nsContainer
 cn: topology
 
-# default topology configuration aere
+# default topology configuration area
 dn: cn=realm,cn=topology,cn=ipa,cn=etc,$SUFFIX
 changetype: add
 objectclass: top
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index c8b08057d52f81ef91c5c88bdc8ea4bbd856110a..a2086c23c36e17d8e24e73e2874701de3dd84239 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -303,7 +303,7 @@ class DsInstance(service.Service):
 self.step("adding range check plugin", self.__add_range_check_plugin)
 if hbac_allow:
 self.step("creating default HBAC rule allow_all", self.add_hbac)
-self.step("adding entries for toplogy management", self.__add_topology_entries)
+self.step("adding entries for topology management", self.__add_topology_entries)
 
 self.__common_post_setup()
 
diff --git a/ipaserver/install/replication.py b/ipaserver/install/replication.py
index 8604d63f8fe06d56f4627bdb2ef3107f5223e550..643639ef4b22f808cc61643309185ec17b321718 100644
--- a/ipaserver/install/replication.py
+++ b/ipaserver/install/replication.py
@@ -416,7 +416,7 @@ class ReplicationManager(object):
 assert isinstance(replica_binddn, DN)
 dn = self.replica_dn()
 assert isinstance(dn, DN)
-replica_groupdn = DN(('cn', 'replication managers'), ('cn=etc'), self.suffix)
+replica_groupdn = DN(('cn', 'replication managers'), ('cn', 'etc'), self.suffix)
 
 try:
 entry = conn.get_entry(dn)
-- 
2.1.0

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH 0048] fix ipa help command output errors

[Gabe Alford]

Hello,

This should fix https://fedorahosted.org/freeipa/ticket/3584, and as
requested in the ticket, this should also fix
https://fedorahosted.org/freeipa/ticket/2284

Thanks,

Gabe
From 3d4e7b60287f30e70455facb0035fa30df913c34 Mon Sep 17 00:00:00 2001
From: Gabe 
Date: Fri, 22 May 2015 07:52:58 -0600
Subject: [PATCH] Fix ipa help command output errors

- Allow ipa help command to run when ipa-client-install is not configured
- Do not print traceback when pipe is broken

https://fedorahosted.org/freeipa/ticket/3584
https://fedorahosted.org/freeipa/ticket/2284
---
 ipalib/cli.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ipalib/cli.py b/ipalib/cli.py
index fc6e2303919d4db724d97f839d9a1b71752dfc10..52529ea02c35a8119a5fb2397d7302d170e81526 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -799,7 +799,10 @@ class help(frontend.Local):
 
 def _writer(self, outfile):
 def writer(string=''):
-print >> outfile, unicode(string)
+try:
+print >> outfile, unicode(string)
+except IOError:
+pass
 return writer
 
 def print_topics(self, outfile):
@@ -1333,7 +1336,7 @@ def run(api):
 api.register(klass)
 api.load_plugins()
 api.finalize()
-if not 'config_loaded' in api.env:
+if not 'config_loaded' in api.env and not 'help' in argv:
 raise NotConfiguredError()
 sys.exit(api.Backend.cli.run(argv))
 except KeyboardInterrupt:
-- 
1.8.3.1

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 854 git ignore ipaplatform/__init__.py

[Petr Vobornik]

On 05/21/2015 09:55 AM, Martin Babinsky wrote:

On 05/20/2015 03:57 PM, Petr Vobornik wrote:

This file is generated in `make version-update`

added in 9f049ca14403f3696d54d186e6b1b15181f055df



Yay no more warnings about untracked file!

ACK



Pushed to master: 5f04da35dfd324686cce33c552839231cc5eba43

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0255] Server Upgrade: Fix: executed schema upgrade

[Petr Vobornik]

On 05/21/2015 04:51 PM, Fraser Tweedale wrote:

On Thu, May 21, 2015 at 02:49:03PM +0200, Martin Basti wrote:

Accidentaly , schema upgrade hasn't beed executed by ipa-server-upgrade.

https://fedorahosted.org/freeipa/ticket/4904

Patch attached.

--
Martin Basti


ACK; the schema changes once again are applied during upgrade.

Thanks,
Fraser



Pushed to master: c43c5d1e437cffacc64220935ee6dd83a8e72a89
--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature

[Tomas Babej]

On 05/22/2015 03:32 PM, Petr Vobornik wrote:

On 05/22/2015 03:18 PM, Petr Vobornik wrote:

On 05/22/2015 01:08 PM, Tomas Babej wrote:

snip



1) 
https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html

- I still don't agree that the plugin should be based on LDAPObject.


On the other hand, with LDAPObject base, Web UI for this feature is
much more simpler because it can rely on existing conventions.


IMHO we can swap the approach in a later patch, if we decide it's
necessary. It does not block or relate to other features much.





2) Use api domainlevel-show call to get the current domain level in
ipa-replica-install instead of duplicating the code.

I chose the former approach since the domainlevel_show command doesn't
need to be available, but yeah, this can be properly detected and 
worked

around too. Fixed.



3) Set the domain level in DSInstance.create_instance instead of a
separate call in ipa-server-install. It should be done about the same
time as the master entry is added.

4) I think the option should be named --domain-level (with a 
dash), for

consistency.





All other issues fixed.

Updated patch atttached


[36/41]: initializing domain level
   [error] TypeError: __set_domain_level() takes exactly 2 arguments (1
given)
Unexpected error - see /var/log/ipaserver-install.log for details:
TypeError: __set_domain_level() takes exactly 2 arguments (1 given)


Install failed



2. during installation, __set_domain_level is called before the Domain 
Level entry is created and hence it fails even if the issue above is 
fixed




Yeah.. we probably need to apply the 72-domainlevel.ldif manually.

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart

[Petr Vobornik]

On 05/21/2015 03:16 PM, Fraser Tweedale wrote:

On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote:

This patch should fix following traceback.

2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to 
'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket':
2015-05-20T03:50:41Z DEBUG Traceback (most recent call last):
   File 
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 
304, in __upgrade
 ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True)
   File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
line 314, in __init__
 self.create_connection()
   File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", 
line 862, in create_connection
 autobind=self.ldapi)
   File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in 
connect
 conn = self.create_connection(*args, **kw)
   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 
188, in create_connection
 client_controls=clientctrls)
   File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1074, in 
external_bind
 '', auth_tokens, server_controls, client_controls)
   File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
 self.gen.throw(type, value, traceback)
   File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 976, in 
error_handler
 error=info)
NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket':

2015-05-20T03:50:41Z DEBUG Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
388, in start_creation
 run_step(full_msg, method)
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
378, in run_step
 method()
   File 
"/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 
315, in __upgrade
 raise RuntimeError(e)
RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket':

Reason was the ipa-server-install tried to connect before DS was ready.

The patch adds waiting until DS is ready.

Patch attached.

Fraser can you please check if this fix works? I can't reproduce it.
Thank you, Martin^2.


ACK; fixes the issue for me.

One minor comment:


+def __start(self):
+super(IPAUpgrade, self).start()

  def __stop_instance(self):
  """Stop only the main DS instance"""
@@ -187,7 +185,7 @@ class IPAUpgrade(service.Service):
  self.step("saving configuration", self.__save_config)
  self.step("disabling listeners", self.__disable_listeners)
  self.step("enabling DS global lock", 
self.__enable_ds_global_write_lock)
-self.step("starting directory server", self.__start_nowait)
+self.step("starting directory server", self.__start)


I think you can just say `self.start' and remove `__start' function.

Cheers,
Fraser



Pushed to master: 3d17bf8e639616893d6937d98662ccc7541d1e23
--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin

[Petr Vobornik]

On 05/21/2015 11:07 AM, thierry bordaz wrote:

Enforcing uniqueness for uid attribute prevent to move users to
delete users subtree.


snip



So is this patch ACKed?


Sorry, yes the fix is good. ACK


master:
* 98e4c6d6de130a0e94cd1705acc5418bdbda1eb1 Uid uniqueness: fix: exclude 
compat tree from uniqueness

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature

[Petr Vobornik]

On 05/22/2015 03:18 PM, Petr Vobornik wrote:

On 05/22/2015 01:08 PM, Tomas Babej wrote:

snip



1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html
- I still don't agree that the plugin should be based on LDAPObject.


On the other hand, with LDAPObject base, Web UI for this feature is
much more simpler because it can rely on existing conventions.


IMHO we can swap the approach in a later patch, if we decide it's
necessary. It does not block or relate to other features much.





2) Use api domainlevel-show call to get the current domain level in
ipa-replica-install instead of duplicating the code.

I chose the former approach since the domainlevel_show command doesn't
need to be available, but yeah, this can be properly detected and worked
around too. Fixed.



3) Set the domain level in DSInstance.create_instance instead of a
separate call in ipa-server-install. It should be done about the same
time as the master entry is added.

4) I think the option should be named --domain-level (with a dash), for
consistency.





All other issues fixed.

Updated patch atttached


[36/41]: initializing domain level
   [error] TypeError: __set_domain_level() takes exactly 2 arguments (1
given)
Unexpected error - see /var/log/ipaserver-install.log for details:
TypeError: __set_domain_level() takes exactly 2 arguments (1 given)


Install failed



2. during installation, __set_domain_level is called before the Domain 
Level entry is created and hence it fails even if the issue above is fixed


--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature

[Petr Vobornik]

On 05/22/2015 01:08 PM, Tomas Babej wrote:

snip



1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html
- I still don't agree that the plugin should be based on LDAPObject.


On the other hand, with LDAPObject base, Web UI for this feature is
much more simpler because it can rely on existing conventions.


IMHO we can swap the approach in a later patch, if we decide it's
necessary. It does not block or relate to other features much.





2) Use api domainlevel-show call to get the current domain level in
ipa-replica-install instead of duplicating the code.

I chose the former approach since the domainlevel_show command doesn't
need to be available, but yeah, this can be properly detected and worked
around too. Fixed.



3) Set the domain level in DSInstance.create_instance instead of a
separate call in ipa-server-install. It should be done about the same
time as the master entry is added.

4) I think the option should be named --domain-level (with a dash), for
consistency.





All other issues fixed.

Updated patch atttached


[36/41]: initializing domain level
  [error] TypeError: __set_domain_level() takes exactly 2 arguments (1 
given)

Unexpected error - see /var/log/ipaserver-install.log for details:
TypeError: __set_domain_level() takes exactly 2 arguments (1 given)


Install failed

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Christian Heimes]

On 2015-05-22 14:02, Petr Vobornik wrote:
> Actually the service part of "IPA servers" is not covered in the
> proposal. The proposal just says that it can be added later.
> 
> There will be question if it should even be called "services". Maybe
> capabilities would be better term given that KDC Proxy is not a
> standalone service.

It's an implementation detail. KDC Proxy shares the Apache HTTP with
webui because it is the simplest way. We don't have to create another
certificate and an additional principal. However in the future that may
change. For high traffic sites a separation of webui and KDC proxy may
make sense. The KKDCP WSGI app has different tuning requirements than webui.

Christian




signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Martin Basti]

On 22/05/15 13:02, Martin Kosek wrote:

On 05/22/2015 12:24 PM, Christian Heimes wrote:

Hello,

since May 1st I'm a new Red Hat employee and developer with the FreeIPA
team. Some of you may already recognize my name from my contributions to
CPython core, Python security and TLS/SSL improvements, or a couple of
PEPs. I'm very glad that I can now work on Open Source as a full time
job. I haven't had any dealings with FreeIPA before and just rudimentary
experience with LDAP and Kerberos as a developer. Over the past two
weeks I have been digging through FreeIPA sources, read docs and played
with its services. I'm slowly starting to grasp the building blocks.

I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The
task is small and isolated enough for a new contributor. KKDCP stands
for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel
KDC requests over HTTPS. It's useful for firewalled environments where
88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With
KKDCP the client side wraps each Kerberos request in an additional ASN.1
sequence and sends it as POST request to a proxy. The proxy unpacks the
request, forwards it to a KDC and returns its reply to the client. MIT
krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12.

Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm
working on improvements and integration of the WSGI app into FreeIPA.
Yesterday several bug fixes already landed in kdcproxy.

The integration into FreeIPA is the tricky part for me. I'm not familiar
enough with FreeIPA yet to understand possible implications, so I need
your guidance. I already got some feedback from several people (Dmitri,
Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...).


Here is what I have so far:

1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy
will run from the same Apache HTTPD instance but it will use a different
mod_wsgi daemon configuration. A second WSGI daemon is easily configured
and allows us to tune the daemon for KDC proxy's needs. FreeIPA is
mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc.


Right.



2) For now we are not going to introduce a separate package
freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy
and install all configuration files. Therefore the entry point /KdcProxy
is always configured


Right.


3) An administrator must be able to enable/disable the new feature. The
state of the switch will be read when Apache is started or reloaded. The
feature must be configurable for each replica, too. A WSGI wrapper will
read the setting from ipaConfigString=enabledService in
cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is
disabled, it will reply with 404 Not Found error.


The original proposal was to do it globally in cn=config. But if it is 
about to be stored in the cn=masters, per-replica, this looks as the 
right way.


What API did you plan using, for enabling/disabling service? If we go 
the general IPA service way, should we extend the planned service-* 
API that Petr Vobornik announced in


http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html

and have command like serverservice-mod ipa.server kdcproxy --enabled=0?






4) In order to read the state of the switch, the WSGI script needs to be
able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to
get a ticket for GSSAPI bind. However Apache has no permission to read
ipaConfigStrings in the masters subtree. A new role/permission and ACI
is required here.


There is already a permission 'System: Read IPA Masters' and privilege 
"IPA Masters Readers" defined, in 
ipaserver/install/plugins/update_managed_permissions.py. Can this be 
used?
Do we want to expose which services are configured and how they are 
configured for apache service? IMO this may be a security issue, to give 
overall read access to configuration of all services on all servers.





5) python-kdcproxy can read its configuration from multiple places. For
performance reasons we don't want DNS lookups. Therefore our proxy
instance will only use libkrb5.so to read a list of KDCs, kpasswd and
admin servers from /etc/krb5.conf.


Ok.


Open questions / issues
---

For 3) and 4) the Apache HTTP principal must be able to read or at least
compare the state of the switch. The ACIs in the masters tree forbid any
access to ipaConfigString entries except for principals with 'System:
Read IPA Masters' permission. Martin Basti and Petr Spacek have
suggested that I introduce a new permission for the task. I haven't
figured out how to configure and assign a new permission. Right now my
experimental code uses this ACI:


(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version 


3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)


I found ipaserver.install.service.Service and SimpleServiceInstance 

[Freeipa-devel] [PATCH 0256] DNS: add UnknonwRecord attribute to schema

[Martin Basti]

Patch attached.

Initial part of https://fedorahosted.org/freeipa/ticket/4939

--
Martin Basti

From 50fd8f7d2d11f963a288c18dd4d1d98c941b7d51 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 22 May 2015 12:39:08 +0200
Subject: [PATCH] DNS: add UnknownRecord to schema

defintion of UnknownRecord attributetype

https://fedorahosted.org/freeipa/ticket/4939
---
 ACI.txt   | 4 ++--
 install/share/60ipadns.ldif   | 3 ++-
 install/share/dns.ldif| 2 +-
 install/updates/40-dns.update | 8 ++--
 ipalib/plugins/dns.py | 4 ++--
 5 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/ACI.txt b/ACI.txt
index bf539892910f14ebc3fbee88a72d2b57c0d1327b..3b6ea6422f5fa831c7c6b9c64748bc9110809489 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -43,13 +43,13 @@ aci: (targetattr = "ipaprivatekey || ipapublickey || ipasecretkey || ipasecretke
 dn: dc=ipa,dc=example
 aci: (targetattr = "cn || idnssecalgorithm || idnsseckeyactivate || idnsseckeycreated || idnsseckeydelete || idnsseckeyinactive || idnsseckeypublish || idnsseckeyref || idnsseckeyrevoke || idnsseckeysep || idnsseckeyzone || objectclass")(target = "ldap:///cn=dns,dc=ipa,dc=example";)(targetfilter = "(objectclass=idnsSecKey)")(version 3.0;acl "permission:System: Manage DNSSEC metadata";allow (all) groupdn = "ldap:///cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: dc=ipa,dc=example
-aci: (targetattr = "a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || createtimestamp || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || entryusn || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || modifytimestamp || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || objectclass || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord")(target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Read DNS Entries";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || createtimestamp || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || entryusn || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || modifytimestamp || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || objectclass || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord || unknownrecord")(target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Read DNS Entries";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: dc=ipa,dc=example
 aci: (targetattr = "cn || createtimestamp || entryusn || idnssecalgorithm || idnsseckeyactivate || idnsseckeycreated || idnsseckeydelete || idnsseckeyinactive || idnsseckeypublish || idnsseckeyref || idnsseckeyrevoke || idnsseckeysep || idnsseckeyzone || modifytimestamp || objectclass")(target = "ldap:///cn=dns,dc=ipa,dc=example";)(targetfilter = "(objectclass=idnsSecKey)")(version 3.0;acl "permission:System: Read DNSSEC metadata";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNSSEC metadata,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: dc=ipa,dc=example
 aci: (target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Remove DNS Entries";allow (delete) groupdn = "ldap:///cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: dc=ipa,dc=example
-aci: (targetattr = "a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || ns

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Petr Vobornik]

On 05/22/2015 01:17 PM, Christian Heimes wrote:

On 2015-05-22 13:02, Martin Kosek wrote:

The original proposal was to do it globally in cn=config. But if it is
about to be stored in the cn=masters, per-replica, this looks as the
right way.


My first proposal used cn=ipaConfig,cn=etc because it was the first
place I found. It took me a bit to find and understand the other
subtrees in cn=etc. Other developers have pointed me to the cn=masters
subtree.


What API did you plan using, for enabling/disabling service? If we go
the general IPA service way, should we extend the planned service-* API
that Petr Vobornik announced in

http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html

and have command like serverservice-mod ipa.server kdcproxy --enabled=0?


I don't have concrete plans for an enabling/disabling API yet. It's one
of the questions I have raised at the end of my mail. I'm going to study
Petr Vobornik's mail now.

In order to disable or enable KDC proxy, the switch in LDAP must be
switched and Apache must be reloaded or restarted. The WSGI wrapper does
NOT poll the state of the switch.


Actually the service part of "IPA servers" is not covered in the 
proposal. The proposal just says that it can be added later.


There will be question if it should even be called "services". Maybe 
capabilities would be better term given that KDC Proxy is not a 
standalone service.






4) In order to read the state of the switch, the WSGI script needs to be
able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to
get a ticket for GSSAPI bind. However Apache has no permission to read
ipaConfigStrings in the masters subtree. A new role/permission and ACI
is required here.


There is already a permission 'System: Read IPA Masters' and privilege
"IPA Masters Readers" defined, in
ipaserver/install/plugins/update_managed_permissions.py. Can this be used?


The permission sounds too broad to me. There is probably a reason why
all ipaConfigStrings entries are read-protected. I really just need
search (and maybe compare) for ipaConfigString=enabledService.

Thanks for your feedback,
Christian





--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Christian Heimes]

On 2015-05-22 13:02, Martin Kosek wrote:
> The original proposal was to do it globally in cn=config. But if it is
> about to be stored in the cn=masters, per-replica, this looks as the
> right way.

My first proposal used cn=ipaConfig,cn=etc because it was the first
place I found. It took me a bit to find and understand the other
subtrees in cn=etc. Other developers have pointed me to the cn=masters
subtree.

> What API did you plan using, for enabling/disabling service? If we go
> the general IPA service way, should we extend the planned service-* API
> that Petr Vobornik announced in
> 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html
> 
> and have command like serverservice-mod ipa.server kdcproxy --enabled=0?

I don't have concrete plans for an enabling/disabling API yet. It's one
of the questions I have raised at the end of my mail. I'm going to study
Petr Vobornik's mail now.

In order to disable or enable KDC proxy, the switch in LDAP must be
switched and Apache must be reloaded or restarted. The WSGI wrapper does
NOT poll the state of the switch.


>> 4) In order to read the state of the switch, the WSGI script needs to be
>> able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to
>> get a ticket for GSSAPI bind. However Apache has no permission to read
>> ipaConfigStrings in the masters subtree. A new role/permission and ACI
>> is required here.
> 
> There is already a permission 'System: Read IPA Masters' and privilege
> "IPA Masters Readers" defined, in
> ipaserver/install/plugins/update_managed_permissions.py. Can this be used?

The permission sounds too broad to me. There is probably a reason why
all ipaConfigStrings entries are read-protected. I really just need
search (and maybe compare) for ipaConfigString=enabledService.

Thanks for your feedback,
Christian




signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature

[Tomas Babej]

On 05/22/2015 12:36 PM, Petr Vobornik wrote:

On 05/22/2015 07:08 AM, Jan Cholasta wrote:

Dne 21.5.2015 v 18:18 Tomas Babej napsal(a):



On 05/19/2015 04:07 PM, Tomas Babej wrote:



On 05/19/2015 03:59 PM, Martin Kosek wrote:

On 05/19/2015 03:56 PM, Tomas Babej wrote:


On 05/19/2015 03:51 PM, Martin Kosek wrote:

On 05/19/2015 03:49 PM, Ludwig Krispenz wrote:

On 05/19/2015 03:36 PM, Martin Kosek wrote:

On 05/19/2015 03:22 PM, Tomas Babej wrote:
...

3) Domain level is just a single integer and it should be
treated as such,
there's no need for an LDAPObject plugin and other unnecessary
complexities.
The implemetation could be as simple as (from top of my head,
untested):

That's right, I also considered this approach, but as far as I
know you do
not
get the permission handling for the global DomainLevel entry
otherwise.

Ludwig, I changed the path for the global entry to 
cn=DomainLevel.

I know this particular DN was added to the design by Simo, but
why do we want
to use CamelCase with LDAP object?

Wouldn't "cn=Domain Level,cn=ipa,cn=etc,SUFFIX" be a better place
for it? This
is the last time we can change it, so I am asking now. Then, we
will be stuck
with this DN forever.

I don't mind using ""cn=Domain Level" ,

but where does the entry live, here you say

cn=Domain Level,cn=ipa,cn=etc,SUFFIX"

and in the design page it is:

cn=DomainLevel,cn=etc,SUFFIX

The current version of the topology plugin is looking for

cn=DomainLevel,cn=ipa,cn=etc,SUFFIX"
but I want to change it to do a search on
objectclass=ipaDomainLevelConfig

I see - we all need to unify the location apparently. I updated the
design page
to use "cn=Domain Level,cn=ipa,cn=etc,SUFFIX". Tomas, please send
the updated
patch set, it should be an extremely simple change :-)

I prefer the ipa parent and the space in the name, so I'm glad we
could agree
on this without much bikeshedding.

Updated patch attaced.

Tomas



I still see

+# Create default Domain Level entry if it does not exist
+dn: cn=DomainLevel,cn=ipa,cn=etc,$SUFFIX
+default: objectClass: top
+default: objectClass: nsContainer
+default: objectClass: ipaDomainLevelConfig
+default: ipaDomainLevel: 0

...


Right, the space eluded me there, thanks for the catch.

Tomas


A new iteration of the patch, including the server-side checks for the
installers.

Tomas


1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html
- I still don't agree that the plugin should be based on LDAPObject.


On the other hand, with LDAPObject base, Web UI for this feature is 
much more simpler because it can rely on existing conventions.


IMHO we can swap the approach in a later patch, if we decide it's 
necessary. It does not block or relate to other features much.






2) Use api domainlevel-show call to get the current domain level in
ipa-replica-install instead of duplicating the code.
I chose the former approach since the domainlevel_show command doesn't 
need to be available, but yeah, this can be properly detected and worked 
around too. Fixed.




3) Set the domain level in DSInstance.create_instance instead of a
separate call in ipa-server-install. It should be done about the same
time as the master entry is added.

4) I think the option should be named --domain-level (with a dash), for
consistency.





All other issues fixed.

Updated patch atttached.

Tomas

From f4894ec2b002d0ddac5dab71233aa78f297993cf Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 14 May 2015 10:49:55 +0200
Subject: [PATCH] Add Domain Level feature

https://fedorahosted.org/freeipa/ticket/5018
---
 ACI.txt|   2 +
 API.txt|  22 ++
 install/share/72domainlevels.ldif  |   6 ++
 install/share/Makefile.am  |   1 +
 install/tools/ipa-replica-install  |  34 +++-
 install/tools/ipa-server-install   |  13 +++-
 install/updates/72-domainlevels.update |  14 
 install/updates/Makefile.am|   1 +
 ipalib/constants.py|   3 +
 ipalib/errors.py   |  16 
 ipalib/plugins/domainlevel.py  | 137 +
 ipaserver/install/dsinstance.py|  15 
 ipaserver/install/ldapupdate.py|   5 ++
 13 files changed, 264 insertions(+), 5 deletions(-)
 create mode 100644 install/share/72domainlevels.ldif
 create mode 100644 install/updates/72-domainlevels.update
 create mode 100644 ipalib/plugins/domainlevel.py

diff --git a/ACI.txt b/ACI.txt
index bf539892910f14ebc3fbee88a72d2b57c0d1327b..d38d1c6f5e7f3095704e2c205a52316b4f39f469 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -50,6 +50,8 @@ dn: dc=ipa,dc=example
 aci: (target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Remove DNS Entries";allow (delete) groupdn = "ldap:///cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: dc=ipa,dc=example
 aci: (targetattr = "a6record || record || afsdbrecord || arecord || ce

Re: [Freeipa-devel] proposal: new API command to list IPA servers

[Martin Kosek]

On 05/21/2015 04:29 PM, Rob Crittenden wrote:

Petr Vobornik wrote:

Hi all,

proposal is to create following two commands:

   ipa server-find
   ipa server-show FQDN

These commands will display a list of IPA servers stored in
cn=masters,cn=ipa,cn=etc,$SUFFIX

No mod and add commands atm. They could be added when needed. Installed
service won't be shown as well.;

Main reasons for adding them are:

1. let people know what they could enter in:
ipa topologysegment-add SUFFIX --leftnode=NODE --rightnode=NODE
2. web ui needs this info to offer a list of IPA servers for the same
task as in #1
3. it's convenient

In Brno, we had an offline discussion about the object name and 'server'
was a winner. Other discussed candidates were: topologynode, node,
master, replica, topologyserver, managedserver. Server was chosen because:
- IPA server is commonly used
- works well with other terminology/commands, e.g. ipa-server-install
- is not bound to topology (in comparison to replica or master)
- is short
- works well with future installation of server parts like CA through API

Adding Rob and Simo to CC explicitly so they could object if they wish ;)


Kudos for including the reasoning. I still lean more towards master but don't
object too much to server given the reasoning.


My main concern with master-* based API was that if we eventually do other type 
of replicas, e.g. read only replicas, they would not longer be "master" and we 
may still want to return them via this API.



My only hesitation to server is
that it is a rather generic term but it seems like a CLI user will quickly
learn the difference between host and server so it should be ok.

+1

rob



--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Martin Kosek]

On 05/22/2015 12:24 PM, Christian Heimes wrote:

Hello,

since May 1st I'm a new Red Hat employee and developer with the FreeIPA
team. Some of you may already recognize my name from my contributions to
CPython core, Python security and TLS/SSL improvements, or a couple of
PEPs. I'm very glad that I can now work on Open Source as a full time
job. I haven't had any dealings with FreeIPA before and just rudimentary
experience with LDAP and Kerberos as a developer. Over the past two
weeks I have been digging through FreeIPA sources, read docs and played
with its services. I'm slowly starting to grasp the building blocks.

I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The
task is small and isolated enough for a new contributor. KKDCP stands
for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel
KDC requests over HTTPS. It's useful for firewalled environments where
88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With
KKDCP the client side wraps each Kerberos request in an additional ASN.1
sequence and sends it as POST request to a proxy. The proxy unpacks the
request, forwards it to a KDC and returns its reply to the client. MIT
krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12.

Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm
working on improvements and integration of the WSGI app into FreeIPA.
Yesterday several bug fixes already landed in kdcproxy.

The integration into FreeIPA is the tricky part for me. I'm not familiar
enough with FreeIPA yet to understand possible implications, so I need
your guidance. I already got some feedback from several people (Dmitri,
Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...).


Here is what I have so far:

1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy
will run from the same Apache HTTPD instance but it will use a different
mod_wsgi daemon configuration. A second WSGI daemon is easily configured
and allows us to tune the daemon for KDC proxy's needs. FreeIPA is
mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc.


Right.



2) For now we are not going to introduce a separate package
freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy
and install all configuration files. Therefore the entry point /KdcProxy
is always configured


Right.


3) An administrator must be able to enable/disable the new feature. The
state of the switch will be read when Apache is started or reloaded. The
feature must be configurable for each replica, too. A WSGI wrapper will
read the setting from ipaConfigString=enabledService in
cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is
disabled, it will reply with 404 Not Found error.


The original proposal was to do it globally in cn=config. But if it is about to 
be stored in the cn=masters, per-replica, this looks as the right way.


What API did you plan using, for enabling/disabling service? If we go the 
general IPA service way, should we extend the planned service-* API that Petr 
Vobornik announced in


http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html

and have command like serverservice-mod ipa.server kdcproxy --enabled=0?



4) In order to read the state of the switch, the WSGI script needs to be
able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to
get a ticket for GSSAPI bind. However Apache has no permission to read
ipaConfigStrings in the masters subtree. A new role/permission and ACI
is required here.


There is already a permission 'System: Read IPA Masters' and privilege "IPA 
Masters Readers" defined, in 
ipaserver/install/plugins/update_managed_permissions.py. Can this be used?



5) python-kdcproxy can read its configuration from multiple places. For
performance reasons we don't want DNS lookups. Therefore our proxy
instance will only use libkrb5.so to read a list of KDCs, kpasswd and
admin servers from /etc/krb5.conf.


Ok.


Open questions / issues
---

For 3) and 4) the Apache HTTP principal must be able to read or at least
compare the state of the switch. The ACIs in the masters tree forbid any
access to ipaConfigString entries except for principals with 'System:
Read IPA Masters' permission. Martin Basti and Petr Spacek have
suggested that I introduce a new permission for the task. I haven't
figured out how to configure and assign a new permission. Right now my
experimental code uses this ACI:


(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)


I found ipaserver.install.service.Service and SimpleServiceInstance in
the FreeIPA sources. As far as I understand the use of the classes, they
are used in the installers to configure service instances. However the
kdcproxy service instance is going to be special. It has no 1:1 relation
to a system service. Instead it shares a s

Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature

[Petr Vobornik]

On 05/22/2015 07:08 AM, Jan Cholasta wrote:

Dne 21.5.2015 v 18:18 Tomas Babej napsal(a):



On 05/19/2015 04:07 PM, Tomas Babej wrote:



On 05/19/2015 03:59 PM, Martin Kosek wrote:

On 05/19/2015 03:56 PM, Tomas Babej wrote:


On 05/19/2015 03:51 PM, Martin Kosek wrote:

On 05/19/2015 03:49 PM, Ludwig Krispenz wrote:

On 05/19/2015 03:36 PM, Martin Kosek wrote:

On 05/19/2015 03:22 PM, Tomas Babej wrote:
...

3) Domain level is just a single integer and it should be
treated as such,
there's no need for an LDAPObject plugin and other unnecessary
complexities.
The implemetation could be as simple as (from top of my head,
untested):

That's right, I also considered this approach, but as far as I
know you do
not
get the permission handling for the global DomainLevel entry
otherwise.

Ludwig, I changed the path for the global entry to cn=DomainLevel.

I know this particular DN was added to the design by Simo, but
why do we want
to use CamelCase with LDAP object?

Wouldn't "cn=Domain Level,cn=ipa,cn=etc,SUFFIX" be a better place
for it? This
is the last time we can change it, so I am asking now. Then, we
will be stuck
with this DN forever.

I don't mind using ""cn=Domain Level" ,

but where does the entry live, here you say

cn=Domain Level,cn=ipa,cn=etc,SUFFIX"

and in the design page it is:

cn=DomainLevel,cn=etc,SUFFIX

The current version of the topology plugin is looking for

cn=DomainLevel,cn=ipa,cn=etc,SUFFIX"
but I want to change it to do a search on
objectclass=ipaDomainLevelConfig

I see - we all need to unify the location apparently. I updated the
design page
to use "cn=Domain Level,cn=ipa,cn=etc,SUFFIX". Tomas, please send
the updated
patch set, it should be an extremely simple change :-)

I prefer the ipa parent and the space in the name, so I'm glad we
could agree
on this without much bikeshedding.

Updated patch attaced.

Tomas



I still see

+# Create default Domain Level entry if it does not exist
+dn: cn=DomainLevel,cn=ipa,cn=etc,$SUFFIX
+default: objectClass: top
+default: objectClass: nsContainer
+default: objectClass: ipaDomainLevelConfig
+default: ipaDomainLevel: 0

...


Right, the space eluded me there, thanks for the catch.

Tomas


A new iteration of the patch, including the server-side checks for the
installers.

Tomas


1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html
- I still don't agree that the plugin should be based on LDAPObject.


On the other hand, with LDAPObject base, Web UI for this feature is much 
more simpler because it can rely on existing conventions.




2) Use api domainlevel-show call to get the current domain level in
ipa-replica-install instead of duplicating the code.

3) Set the domain level in DSInstance.create_instance instead of a
separate call in ipa-server-install. It should be done about the same
time as the master entry is added.

4) I think the option should be named --domain-level (with a dash), for
consistency.




--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Christian Heimes]

Hello,

since May 1st I'm a new Red Hat employee and developer with the FreeIPA
team. Some of you may already recognize my name from my contributions to
CPython core, Python security and TLS/SSL improvements, or a couple of
PEPs. I'm very glad that I can now work on Open Source as a full time
job. I haven't had any dealings with FreeIPA before and just rudimentary
experience with LDAP and Kerberos as a developer. Over the past two
weeks I have been digging through FreeIPA sources, read docs and played
with its services. I'm slowly starting to grasp the building blocks.

I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The
task is small and isolated enough for a new contributor. KKDCP stands
for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel
KDC requests over HTTPS. It's useful for firewalled environments where
88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With
KKDCP the client side wraps each Kerberos request in an additional ASN.1
sequence and sends it as POST request to a proxy. The proxy unpacks the
request, forwards it to a KDC and returns its reply to the client. MIT
krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12.

Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm
working on improvements and integration of the WSGI app into FreeIPA.
Yesterday several bug fixes already landed in kdcproxy.

The integration into FreeIPA is the tricky part for me. I'm not familiar
enough with FreeIPA yet to understand possible implications, so I need
your guidance. I already got some feedback from several people (Dmitri,
Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...).


Here is what I have so far:

1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy
will run from the same Apache HTTPD instance but it will use a different
mod_wsgi daemon configuration. A second WSGI daemon is easily configured
and allows us to tune the daemon for KDC proxy's needs. FreeIPA is
mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc.

2) For now we are not going to introduce a separate package
freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy
and install all configuration files. Therefore the entry point /KdcProxy
is always configured

3) An administrator must be able to enable/disable the new feature. The
state of the switch will be read when Apache is started or reloaded. The
feature must be configurable for each replica, too. A WSGI wrapper will
read the setting from ipaConfigString=enabledService in
cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is
disabled, it will reply with 404 Not Found error.

4) In order to read the state of the switch, the WSGI script needs to be
able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to
get a ticket for GSSAPI bind. However Apache has no permission to read
ipaConfigStrings in the masters subtree. A new role/permission and ACI
is required here.

5) python-kdcproxy can read its configuration from multiple places. For
performance reasons we don't want DNS lookups. Therefore our proxy
instance will only use libkrb5.so to read a list of KDCs, kpasswd and
admin servers from /etc/krb5.conf.


Open questions / issues
---

For 3) and 4) the Apache HTTP principal must be able to read or at least
compare the state of the switch. The ACIs in the masters tree forbid any
access to ipaConfigString entries except for principals with 'System:
Read IPA Masters' permission. Martin Basti and Petr Spacek have
suggested that I introduce a new permission for the task. I haven't
figured out how to configure and assign a new permission. Right now my
experimental code uses this ACI:


(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)


I found ipaserver.install.service.Service and SimpleServiceInstance in
the FreeIPA sources. As far as I understand the use of the classes, they
are used in the installers to configure service instances. However the
kdcproxy service instance is going to be special. It has no 1:1 relation
to a system service. Instead it shares a system service (Apache HTTPD)
with the HttpInstance for FreeIPA's webui. AFAIK no other service
instance has such a relation.


Finally I haven't figured out the best way to configure the instance. An
admin should be able to enable / disable KDC proxy. Should I write a
script or a ipa plugin for the job?


You can find my patch in my Github repos [4]. The installer code is
mostly untested, though.


Please advice :)
Christian


[1] https://www.freeipa.org/page/V4/KDC_Proxy
[2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html
[3] https://github.com/npmccallum/kdcproxy
[4] https://github.com/tiran/freeipa/compare/master...kdcproxy2



signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for th

Re: [Freeipa-devel] [PATCH 0339-0363] Implement meta-database

[Tomas Hozza]

On 05/15/2015 11:37 AM, Petr Spacek wrote:
> Hello,
>
> this patch set adds meta-database which is one of prerequisites for other 
> work.
>
> These changes should not be user-visible. You might compile the plugin with
> CFLAGS="-DMETADB_DEBUG" and check contect of /tmp/metadb.db after BIND 
> shutdown.
>
> Please see
> https://fedorahosted.org/bind-dyndb-ldap/ticket/151
> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/MetaDB
> for further information and let me know if you can help you somehow.
>

In Patch 351 Rename ldap_entry_create() to ldap_entry_parse(), you should
rename the functions also in documentation:
https://github.com/pspacek/bind-dyndb-ldap/blob/4fb7bd42609c2b6a4ffbdf6f3a1e58e00d84fa1e/src/ldap_entry.c#L111
https://github.com/pspacek/bind-dyndb-ldap/blob/4fb7bd42609c2b6a4ffbdf6f3a1e58e00d84fa1e/src/ldap_entry.h#L101

Other than that, it looks good.

I did no functional testing... It compiled, functional testing done by others.

ACK

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.   http://cz.redhat.com

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597)

[Petr Spacek]

On 18.5.2015 17:31, Petr Spacek wrote:
> Hello,
> 
> This patch is unrelated to metaDB but it should be merged before alpha, too.
> 
> Thank you for review!
> 
> Support unknown record types (RFC 3597).
> 
> Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to
> add specific attribute like "URIRecord" failed with 
> LDAP_OBJECT_CLASS_VIOLATION
> and always delete both attributes like "URIRecord" and 
> "UnknownRecord;TYPE256".
> 
> https://fedorahosted.org/bind-dyndb-ldap/ticket/157

Fixed version is attached. Version 1 could dereference NULL pointers in second
iteration of while loops.

-- 
Petr^2 Spacek
From 0e41cb1b3db9c08b891206b2d6a0a2113a4cf00a Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 16 Mar 2015 22:40:36 +0100
Subject: [PATCH] Support unknown record types (RFC 3597).

Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to
add specific attribute like "URIRecord" failed with LDAP_OBJECT_CLASS_VIOLATION
and always delete both attributes like "URIRecord" and "UnknownRecord;TYPE256".

https://fedorahosted.org/bind-dyndb-ldap/ticket/157
---
 src/ldap_convert.c | 67 -
 src/ldap_convert.h | 13 ++--
 src/ldap_driver.c  |  9 ++---
 src/ldap_helper.c  | 96 +++---
 src/ldap_helper.h  |  5 +--
 5 files changed, 150 insertions(+), 40 deletions(-)

diff --git a/src/ldap_convert.c b/src/ldap_convert.c
index dde10d6e989159e9f6f5086a4a12bbd165b73646..0bdb83547bec74d0f2954a4e8443ef2b70347cf8 100644
--- a/src/ldap_convert.c
+++ b/src/ldap_convert.c
@@ -19,11 +19,13 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -394,33 +396,80 @@ ldap_attribute_to_rdatatype(const char *ldap_attribute, dns_rdatatype_t *rdtype)
 
 	/* Does attribute name end with RECORD_SUFFIX? */
 	if (strcasecmp(ldap_attribute + len - LDAP_RDATATYPE_SUFFIX_LEN,
-		   LDAP_RDATATYPE_SUFFIX))
+		   LDAP_RDATATYPE_SUFFIX) == 0) {
+		region.base = ldap_attribute;
+		region.length = len - LDAP_RDATATYPE_SUFFIX_LEN;
+	/* Does attribute name start with with UNKNOWN_PREFIX? */
+	} else if (strncasecmp(ldap_attribute,
+			  LDAP_RDATATYPE_UNKNOWN_PREFIX,
+			  LDAP_RDATATYPE_UNKNOWN_PREFIX_LEN) == 0) {
+		region.base = ldap_attribute + LDAP_RDATATYPE_UNKNOWN_PREFIX_LEN;
+		region.length = len - LDAP_RDATATYPE_UNKNOWN_PREFIX_LEN;
+	} else
 		return ISC_R_UNEXPECTED;
 
-	region.base = ldap_attribute;
-	region.length = len - LDAP_RDATATYPE_SUFFIX_LEN;
 	result = dns_rdatatype_fromtext(rdtype, (isc_textregion_t *)®ion);
 	if (result != ISC_R_SUCCESS)
 		log_error_r("dns_rdatatype_fromtext() failed for attribute '%s'",
 			ldap_attribute);
 
 	return result;
 }
 
+/**
+ * Convert DNS rdata type to LDAP attribute name.
+ *
+ * @param[in]  rdtype
+ * @param[out] target   Output buffer with \0 terminated attribute name.
+ * @param[in]  size Target size.
+ * @param[in]  unknown  ISC_TRUE = use generic syntax "UnknownRecord;TYPE65333",
+ *  ISC_FALSE = use type-specific mnemonic like "ARecord"
+ */
 isc_result_t
 rdatatype_to_ldap_attribute(dns_rdatatype_t rdtype, char *target,
-			unsigned int size)
+			unsigned int size, isc_boolean_t unknown)
 {
 	isc_result_t result;
 	char rdtype_str[DNS_RDATATYPE_FORMATSIZE];
 
-	dns_rdatatype_format(rdtype, rdtype_str, DNS_RDATATYPE_FORMATSIZE);
-	CHECK(isc_string_copy(target, size, rdtype_str));
-	CHECK(isc_string_append(target, size, LDAP_RDATATYPE_SUFFIX));
-
-	return ISC_R_SUCCESS;
+	if (unknown) {
+		/* "UnknownRecord;TYPE65333" */
+		CHECK(isc_string_copy(target, size,
+  LDAP_RDATATYPE_UNKNOWN_PREFIX));
+		snprintf(rdtype_str, sizeof(rdtype_str), "TYPE%u", rdtype);
+		CHECK(isc_string_append(target, size, rdtype_str));
+	} else {
+		/* "ARecord" */
+		dns_rdatatype_format(rdtype, rdtype_str, DNS_RDATATYPE_FORMATSIZE);
+		CHECK(isc_string_copy(target, size, rdtype_str));
+		CHECK(isc_string_append(target, size, LDAP_RDATATYPE_SUFFIX));
+	}
 
 cleanup:
 	return result;
 }
 
+/**
+ * Convert rdata to generic (RFC 3597) format.
+ */
+isc_result_t
+rdata_to_generic(dns_rdata_t *rdata, isc_buffer_t *target)
+{
+	isc_result_t result;
+	isc_region_t rdata_reg;
+	char buf[sizeof("\\# 65535")];
+
+	dns_rdata_toregion(rdata, &rdata_reg);
+	REQUIRE(rdata_reg.length <= 65535);
+
+	result = isc_string_printf(buf, sizeof(buf), "\\# %u", rdata_reg.length);
+	INSIST(result == ISC_R_SUCCESS);
+	isc_buffer_putstr(target, buf);
+	if (rdata_reg.length != 0U) {
+		isc_buffer_putstr(target, " ");
+		CHECK(isc_hex_totext(&rdata_reg, 0, "", target));
+	}
+
+cleanup:
+	return result;
+}
diff --git a/src/ldap_convert.h b/src/ldap_convert.h
index daa0db0b311dd51c05ade688715550d9f70759ac..3810468af5591dbef1776c5e1ca91764b53df126 100644
--- a/src/ldap_convert.h
+++ b/src/ldap_convert.h
@@ -28,8 +28,10 @@
 #include "zone_register.h"
 
 #define LDAP_ATTR_FORMATSIZE 32 /* "expected" maximum att

Re: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types

[Petr Spacek]

On 22.5.2015 09:22, Martin Kosek wrote:
> On 05/22/2015 09:17 AM, Martin Basti wrote:
>> On 21/05/15 12:42, Petr Spacek wrote:
>>> Hello,
>>>
>>> Add schema for unknown record types.
>>>
>>> This patch complements my previous patch 367.
>>>
>>> The change was pushed to
>>> https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types  , too.
>>>
>>>
>>>
>> ACK
> 
> Hmmm, I wish the LDAP attribute is named differently, "UnknownRecord" is too
> general IMO. But I assume this is something you have thought about already, I
> just wanted to make sure the reasoning is included before pushing this.

Sorry, it is too late.

It was discussed on ipa-devel list and Honza seemed to insist on this name :-)

More importantly, it is already in UNINETT schema upstream:
http://drift.uninett.no/nett/ip-nett/dnsattributes.schema
http://drift.uninett.no/nett/ip-nett/oids.html

It might be generic but is is consistent with RFC & rest of DNS attributes.


Personally I'm more worried about brain-dead idnsRecord object class
definition :-)

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types

[Martin Kosek]

On 05/22/2015 09:17 AM, Martin Basti wrote:

On 21/05/15 12:42, Petr Spacek wrote:

Hello,

Add schema for unknown record types.

This patch complements my previous patch 367.

The change was pushed to
https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types  , too.




ACK


Hmmm, I wish the LDAP attribute is named differently, "UnknownRecord" is too 
general IMO. But I assume this is something you have thought about already, I 
just wanted to make sure the reasoning is included before pushing this.


--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types

[Martin Basti]

On 21/05/15 12:42, Petr Spacek wrote:

Hello,

Add schema for unknown record types.

This patch complements my previous patch 367.

The change was pushed to
https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too.




ACK

--
Martin Basti

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management

[Martin Kosek]

On 05/21/2015 05:33 PM, Martin Basti wrote:

On 20/05/15 16:41, Fraser Tweedale wrote:

Hi Honza, Martin et al,

Latest patches attached.  On top of previous patches (most review
matters addressed**) patches 0008..0011 add support for profiles and
user certificates to `ipa cert-request'.

** those that were not are being tracked at [1]; please add anything
I missed.

Some points to note:

- usercertificate is not yet a multi-valued attribute for users,
   hosts and services.


It should be multivalued now, for all 3 entities.


   QUESTION - we do want to allow multiple certificates for all
   principal types, not just users?  Or have I got that wrong.


You have that right (unless I miss something).


Changing schema can cause issues in future, we already burn ourselves several
times.
If you plan to have multi valued attribute in close future, could be better to
have mutltivalued schema now, instead of make this change in future?


+1. In general, it is better to do the schema right from the day 0, temporary 
limitations should be rather solved in framework - that is easier to change.




- "DN and SAN match principal" checks are not implemented for users
   yet.

- ACL was added to allow user principals to request their own
   certificates, however, this will be further subject to CA/profile
   ACLs which are to come.

- Pursuant to [2] revocation logic was removed from `cert-request'

[1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress
[2]
http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates

Thanks,
Fraser


Thank you too.

Martin

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code