Re: [Freeipa-devel] [PATCH] 272-273 Add service membership to host objects
On Tue, 2012-06-05 at 17:35 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > This set of patches > > 1) Adds a support for uni-directional remote membership to baseldap > > plugin (like service->host membership in service managedby attribute) - > > patch 272 > > 2) Adds a support for service->host membership to host plugin using the > > new interface - patch 273 > > > > Martin > > Have you tried this in the UI? Are these new relationships already handled? > > rob I just checked that I didn't break anything in the host page. But with this patch, we could add a tab with a list of services for a selected host. I will check with Petr if the information we provide are enough. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] About private ssh host keys in IPA
On 06/05/2012 05:02 PM, Sigbjorn Lie wrote: > On 06/05/2012 04:38 PM, Jérôme Fenal wrote: >> 2012/6/5 Sigbjorn Lie mailto:sigbj...@nixtra.com>> >> >> >> >> On Fri, June 1, 2012 15:24, Simo Sorce wrote: >> > This is about Ticket 1978 (originally rhbz746036). >> > >> > >> > This RFE asks for storing private SSH Host Keys in FreeIPA. >> > >> > >> > We have been triaging this ticket today, and I have to admit I >> am biased >> > toward simply closing down the ticket. >> > >> > However we want to reach out community and interested parties that >> > opened the tick to understand if there are reasons strong >> enough to consider implementing it. >> > >> > The reason I am against this is that in FreeIPA we already provide >> > public Key integration. This means that when the host is >> re-installed new keys are loaded in IPA >> > and clients do not get the obnoxious warning message that keys >> have changed, because enrolled >> > clients (with the appropriate integration bits) trust FreeIPA >> so they do not need to ask the user >> > to confirm on a key change. >> > >> > Storing Private Keys poses various liability issues, in order >> to be able >> > to restore keys you need to give access to those keys to an >> admin, as there is no other way to >> > authenticate just the host itself (it was just blown away and >> reinstalled). This means any admin >> > account that can perform reinstalls need to have access to >> *read* private keys out of LDAP, which >> > means that A) The central tenet of Asymetric authentication is >> that private keys >> > are 'private'. B) keys are readable from LDAP to some accounts, >> any slight error in >> > ACIs would risk exposing all private keys. >> > C) most probably low level (junior admin) accounts will have >> read access >> > to pretty much all private keys, because those admins are the >> one tasked with re-installs. However >> > those admins are also the ones less trusted, yet by giving them >> access to private keys they are >> > enabled to perform MITM attacks against pretty much any of the >> machines managed by FreeIPA. >> > >> > >> > For these reasons I am against storing SSH Private Keys. I >> would like to >> > know what are the reasons to instead implement this feature and >> the security considerations around >> > those reasons. >> >> From my point of view the balance between feature vs security >> issues >> >> >> > trips in disfavor of implementing the feature but I am willing >> to be convinced otherwise if there >> > are good reasons to, and security issues can be properly >> addressed with some clever scheme. >> > >> >> >> I think there has been some confusion here. What I was looking >> for was a way to prevent the users >> from receiving a message when ssh'ing into a host that's been >> reinstalled, that the host's key has >> changed. >> >> I believe will become availabe in the future version IPA 2.2 / >> RHEL 6.3? >> >> >> So what you're looking for is an automatic deployment of known_hosts >> in a centralised way (/etc/ssh) each time a new machine is deployed >> in an IPA domain ? >> > > No, I would like not having to update the existing known_hosts when a > host is re-installed. > But the ssh feature of IPA and SSSD will automatically maintain known_hosts for you so it looks like the problem will be solved with what we have in 2.2 have you given it a try? > > Rgds, > Siggi > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0058 Prevent deletion of the last admin
Petr Viktorin wrote: Raise an error when trying to delete the last user from the 'admins' group The 'admin' group name seems like something that shouldn't be hardcoded, but that's how it's done in the webui and some of our ACIs, and I don't see another solution short of adding a new attribute. https://fedorahosted.org/freeipa/ticket/2564 This looks ok, I think it should go further and prevent the last member to be removed from the admins group too. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 272-273 Add service membership to host objects
Martin Kosek wrote: This set of patches 1) Adds a support for uni-directional remote membership to baseldap plugin (like service->host membership in service managedby attribute) - patch 272 2) Adds a support for service->host membership to host plugin using the new interface - patch 273 Martin Have you tried this in the UI? Are these new relationships already handled? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] About private ssh host keys in IPA
On 06/05/2012 04:38 PM, Jérôme Fenal wrote: 2012/6/5 Sigbjorn Lie mailto:sigbj...@nixtra.com>> On Fri, June 1, 2012 15:24, Simo Sorce wrote: > This is about Ticket 1978 (originally rhbz746036). > > > This RFE asks for storing private SSH Host Keys in FreeIPA. > > > We have been triaging this ticket today, and I have to admit I am biased > toward simply closing down the ticket. > > However we want to reach out community and interested parties that > opened the tick to understand if there are reasons strong enough to consider implementing it. > > The reason I am against this is that in FreeIPA we already provide > public Key integration. This means that when the host is re-installed new keys are loaded in IPA > and clients do not get the obnoxious warning message that keys have changed, because enrolled > clients (with the appropriate integration bits) trust FreeIPA so they do not need to ask the user > to confirm on a key change. > > Storing Private Keys poses various liability issues, in order to be able > to restore keys you need to give access to those keys to an admin, as there is no other way to > authenticate just the host itself (it was just blown away and reinstalled). This means any admin > account that can perform reinstalls need to have access to *read* private keys out of LDAP, which > means that A) The central tenet of Asymetric authentication is that private keys > are 'private'. B) keys are readable from LDAP to some accounts, any slight error in > ACIs would risk exposing all private keys. > C) most probably low level (junior admin) accounts will have read access > to pretty much all private keys, because those admins are the one tasked with re-installs. However > those admins are also the ones less trusted, yet by giving them access to private keys they are > enabled to perform MITM attacks against pretty much any of the machines managed by FreeIPA. > > > For these reasons I am against storing SSH Private Keys. I would like to > know what are the reasons to instead implement this feature and the security considerations around > those reasons. >> From my point of view the balance between feature vs security issues >> > trips in disfavor of implementing the feature but I am willing to be convinced otherwise if there > are good reasons to, and security issues can be properly addressed with some clever scheme. > I think there has been some confusion here. What I was looking for was a way to prevent the users from receiving a message when ssh'ing into a host that's been reinstalled, that the host's key has changed. I believe will become availabe in the future version IPA 2.2 / RHEL 6.3? So what you're looking for is an automatic deployment of known_hosts in a centralised way (/etc/ssh) each time a new machine is deployed in an IPA domain ? No, I would like not having to update the existing known_hosts when a host is re-installed. Rgds, Siggi ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] 43 Inherit nssldap security access settings during replica install
Rob Crittenden wrote:
JR Aquino wrote:
When making adjustments to increase the bind security settings of a
FreeIPA server, it is best practice to inherit those settings when
installing a new replica server.
Inherit the following bind security settings when performing a replica
install:
'nsslapd-allow-unauthenticated-binds',
'nsslapd-require-secure-binds',
'nsslapd-allow-anonymous-access',
'nsslapd-minssf'
https://fedorahosted.org/freeipa/ticket/1930
NACK
There is a connection helper in service.py you can use, ldap_connect().
Use it like:
if not self.admin_conn:
self.ldap_connect()
x = self.conn.addEntry(foo)
I rebased the patch to master and re-worked it a bit. JR, what do you think?
rob
>From 0f6b65a168b9e6187a047036615e18c49fafa6ba Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Tue, 5 Jun 2012 17:14:52 -0400
Subject: [PATCH] Inherit security access settings during replica install
Inherit the following bind security settings when performing a replica
install:
'nsslapd-allow-unauthenticated-binds',
'nsslapd-require-secure-binds',
'nsslapd-allow-anonymous-access',
'nsslapd-minssf'
https://fedorahosted.org/freeipa/ticket/1930
---
install/tools/ipa-replica-install | 16
ipaserver/install/dsinstance.py |7 +++
2 files changed, 23 insertions(+)
diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index d162b01f281177454240e17140f12b49a24890c4..c331ac250d399d871dc35fd2ea7d37e70110e737 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -427,6 +427,16 @@ def main():
pass
if found:
sys.exit(3)
+# Fetch anonymous bind security settings
+inherited_settings = {}
+sec_attrs = ['nsslapd-allow-unauthenticated-binds',
+'nsslapd-require-secure-binds',
+'nsslapd-allow-anonymous-access',
+'nsslapd-minssf']
+try:
+inherited_settings.update(conn.get_entry(u'cn=config', sec_attrs)[1])
+except errors.NotFound:
+pass
except errors.ACIError:
sys.exit("\nThe password provided is incorrect for LDAP server %s" % config.master_host_name)
except errors.LDAPError:
@@ -473,6 +483,10 @@ def main():
service.print_msg("Applying LDAP updates")
ds.apply_updates()
+# Inherit bind security settings
+service.print_msg("Inheriting bind security settings")
+ds.inherit_security_settings(inherited_settings)
+
# Restart ds and krb after configurations have been changed
service.print_msg("Restarting the directory server")
ds.restart()
@@ -502,6 +516,8 @@ def main():
print "ipa-client-install returned: " + str(e)
raise RuntimeError("Failed to configure the client")
+ds.ldapi = True
+ds.realm = ds.realm_name
ds.replica_populate()
#Everything installed properly, activate ipa service.
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index b7f2f3ec81276ea893e124fe05fea9f7f26f95c7..49927bf41e67d6efbba76365d14f60686f19473e 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -503,6 +503,13 @@ class DsInstance(service.Service):
def generate_random(self):
return ipautil.ipa_generate_password()
+def inherit_security_settings(self, inherited_settings):
+
+if not self.admin_conn:
+self.ldap_connect()
+mod = [(ldap.MOD_REPLACE, key, str(inherited_settings[key][0])) for key in inherited_settings]
+self.admin_conn.modify_s('cn=config', mod)
+
def __enable_ssl(self):
dirname = config_dirname(self.serverid)
dsdb = certs.CertDB(self.realm_name, nssdir=dirname, subject_base=self.subject_base)
--
1.7.10.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 41-2 During ipa-client-install verify forward and reverse dns lookup of server
JR Aquino wrote: On Feb 28, 2012, at 10:43 AM, JR Aquino wrote: On Feb 23, 2012, at 3:56 PM, JR Aquino wrote: ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py ipa-client-install does not currently have an equivalent This patch adds valid_dns to ipapython/ipautil.py to validate foward and reverse DNS This patch adds the valid_dns test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server https://fedorahosted.org/freeipa/ticket/2438 Rebased and corrected patch NEW Rebased and corrected patch Is it possible to rebase this to master? I looked at it briefly and there is going to be an import loop if you try adding this to ipapython/ipautil. I'm not sure if the best solution is to move some things from ipalib/util into ipapython/ipautil or not, but it is certainly the simplest. I think the approach is right, the code has just shifted significantly since 2.2 (new DNS resolver). thanks rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 1023 tool for configuring automount
Here is a tool that can be used to configure automount in an IPA client.
It can use either SSSD or autofs for automount. It also configures NFSv4
on the client so secure maps will work.
rob
>From 4229bd509164ea2ae00a6fb76cfc3b2a174a4847 Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Tue, 29 May 2012 14:20:38 -0400
Subject: [PATCH] Configure automount using autofs or sssd.
This script edits nsswitch.conf to use either ldap (autofs) or
sss (sssd) to find automount maps.
NFSv4 services are started so Kerberos encryption and/or integrity can
be used on the maps.
https://fedorahosted.org/freeipa/ticket/1233
---
freeipa.spec.in| 10 +
ipa-client/ipa-install/Makefile.am |1 +
ipa-client/ipa-install/ipa-configure-automount | 437
ipa-client/man/Makefile.am |1 +
ipa-client/man/ipa-configure-automount.1 | 88 +
ipapython/platform/base.py |3 +-
ipapython/platform/fedora16.py |3 +
7 files changed, 542 insertions(+), 1 deletion(-)
create mode 100755 ipa-client/ipa-install/ipa-configure-automount
create mode 100644 ipa-client/man/ipa-configure-automount.1
diff --git a/freeipa.spec.in b/freeipa.spec.in
index de93aecb6142f73528e6aefe89d6bfcb48fc036f..44bf5bbcd31e54b9f29b4c72d12bc4a04ae785af 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -222,6 +222,10 @@ Requires: bind-utils
Requires: oddjob-mkhomedir
Requires: python-krbV
Requires: python-dns
+Requires: libsss_autofs
+Requires: autofs
+Requires: libnfsidmap
+Requires: nfs-utils
Obsoletes: ipa-client >= 1.0
@@ -639,6 +643,7 @@ fi
%defattr(-,root,root,-)
%doc COPYING README Contributors.txt
%{_sbindir}/ipa-client-install
+%{_sbindir}/ipa-configure-automount
%{_sbindir}/ipa-getkeytab
%{_sbindir}/ipa-rmkeytab
%{_sbindir}/ipa-join
@@ -653,6 +658,7 @@ fi
%{_mandir}/man1/ipa-getkeytab.1.gz
%{_mandir}/man1/ipa-rmkeytab.1.gz
%{_mandir}/man1/ipa-client-install.1.gz
+%{_mandir}/man1/ipa-configure-automount.1.gz
%{_mandir}/man1/ipa-join.1.gz
%{_mandir}/man5/default.conf.5.gz
@@ -684,6 +690,10 @@ fi
%ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt
%changelog
+* Fri Jun 1 2012 Martin Kosek - 2.99.0-30
+- Add client requires on libsss-autofs, autofs, libnfsidmap and nfs-utils
+ for configuring automount and NFS.
+
* Fri May 11 2012 Martin Kosek - 2.99.0-29
- Replace used DNS client library (acutil) with python-dns
diff --git a/ipa-client/ipa-install/Makefile.am b/ipa-client/ipa-install/Makefile.am
index ad0c4e0cadb39d30824ea176eefd5201985bd462..0fa94c1f33b631e70f6809439027458ba34da8b2 100644
--- a/ipa-client/ipa-install/Makefile.am
+++ b/ipa-client/ipa-install/Makefile.am
@@ -2,6 +2,7 @@ NULL =
sbin_SCRIPTS = \
ipa-client-install \
+ ipa-configure-automount \
$(NULL)
EXTRA_DIST = \
diff --git a/ipa-client/ipa-install/ipa-configure-automount b/ipa-client/ipa-install/ipa-configure-automount
new file mode 100755
index ..57e4180227398f73b43e0132cead0d32221e1dd5
--- /dev/null
+++ b/ipa-client/ipa-install/ipa-configure-automount
@@ -0,0 +1,437 @@
+#!/usr/bin/env python
+#
+# Authors:
+# Rob Crittenden
+#
+# Copyright (C) 2012 Red Hat
+# see file 'COPYING' for use and warranty information
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see
Re: [Freeipa-devel] [PATCH] 151, 152 Removal of illegal options in association dialog
If I understood correctly the json_exclude_attrs already defines the list of attributes to be excluded, so is it still necessary to define json_only_presence_options which basically will remove all attributes except name? Suppose later you're writing the UI console where you can type the CLI commands in the UI, do you think attributes like doc would be needed to show in the command help? If this is fine then ACK on both. Btw, the static test data (i.e. ipa_init_*.json) should be updated as well. You might want to create some scripts in install/ui/test/bin to update these files similar to update_ipa_init.sh. On 6/4/2012 11:05 AM, Petr Vobornik wrote: [PATCH] 152 Removal of illegal options in association dialog: Association dialogs were using non-existent options for find commands. It causes error when #2509 is implemented. Now when creating a find command a check for options existence is performed. Option is not used if not present in metadata. It fixes the issue. To be able to do the this check properly patch 151 is required. [PATCH] 151 Change json serialization to serialize useful data: json_metadata command creates and sends metadata needed by Web UI. It uses __json__ method for serialization of commands, options, objects... . A lot of data sent was useless for Web UI and some usefull information were missing. We * mostly CLI specific option attribues are not send. * attributes evaluated to false or None are not send * options which are send are not got from takes_aptions attribute but by get_options() method. It finally sends usefull option collection for commands part of metadata. In the end the raw amount of data send is aproximately the same. This patch is needed for Web UI to determine which option it can use in which commands. https://fedorahosted.org/freeipa/ticket/2760 -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0057 Skip the fix_replica_memberof update plugin for non-root users
On 06/05/2012 04:18 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 06/05/2012 03:00 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 06/05/2012 10:06 AM, Martin Kosek wrote: On Mon, 2012-06-04 at 11:51 -0400, Simo Sorce wrote: On Mon, 2012-06-04 at 17:22 +0200, Petr Viktorin wrote: An update plugin needed root privileges, and aborted the update if an ordinary user user ran it. With this patch the plugin is skipped with a warning in that case. https://fedorahosted.org/freeipa/ticket/2621 Hi Petr, I am not sure I like the proposed solution. If there is a legitimate reason to run this plugin as non-root (eg admin user) then you should change the connection part to try to use GSSAPI auth over ldap when non-root, not just throw a warning. If there is no reason for anyone but root to run this script then we should just abort if not root IMO. Simo. I would keep this script runable for root users only. Regularly, this should not be run manually but as a part of RPM update which is done by root. It is being run manually only when something is broken anyway and I am not convinced that non-root users should be involved in such recovery. Martin Thanks for the advice. The attached patch only allows root to run ipa-ldap-updater. NACK. It is very handy for developers to be able to run ipa-ldap-updater to test update files. rob Developers can run it as root, I don't see a problem here. I'd really rather not. This does nothing requiring root permissions, it's all done over LDAP. I'd rather trade not running some plugins than always requiring root. rob Thanks for info on how the tool is used. I looked into it deeper. The proper fix would be to use the ldap2 backend here, instead of the IPAdmin. That's ticket 2660, and it'll be quite a lot of work to get ReplicationManager and tools that depend on that ported. But, I think it makes sense to require root if (and only if) plugins are run. Justification below. Would that work for your use case? There are currently three modes ipa-ldap-updater can run in: 1) --upgrade (needs root, runs plugins) 2) no --upgrade, either no files specified or --plugins (doesn't need root, runs plugins) 3) no --upgrade, specific files specified without --plugins (doesn't need root, doesn't run plugins) I propose to make mode 2 require root. There are two major uses of the script: install/upgrade (first two modes), and a developer testing update files (third or possibly second mode). Install/upgrade is always run as root, and the developer usually doesn't need to run the plugins (if they do, they should run as root anyway, so that some (parts of) plugins aren't skipped). Some of the plugins ask to restart the DS. Without root privileges, the restart (but not the rest of the plugin) is skipped. I think this is just asking for trouble. Some plugins (or parts of plugins) don't need root, but I don't think singling these out and testing both cases is worth the effort. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0042-0048 AD trusts support (master)
- Original Message - > On Mon, Jun 04, 2012 at 03:32:36PM +0300, Alexander Bokovoy wrote: > > On Mon, 04 Jun 2012, Martin Kosek wrote: > > >I did another round of testing and this is what I found so far: > > > > > >1) freeipa.spec.in was missing python-crypto BuildRequires (you > > >fixed > > >that) > > > > > >2) Unit tests need to be updated, currently there is about a dozen > > >test > > >case errors, e.g. extra ipakrbprincipalalias attribute in services > > >or > > >new ipakrbprincipal objectclass for hosts > > Ok, will fix. > > > > >3) Replication did not work too well for me this time. > > >ipa-replica-install reported just one issue during installation > > >process: > > > > > >2012-06-04T09:42:51Z DEBUG [24/30]: enabling S4U2Proxy > > >delegation > > >2012-06-04T09:42:51Z DEBUG args=/usr/bin/ldapmodify -h > > >vm-057.idm.lab.bos.redhat.com -v -f /tmp/ tmpifHccf -x -D > > >cn=Directory Manager -y /tmp/tmppqaAdV > > >2012-06-04T09:42:51Z DEBUG stdout= > > >2012-06-04T09:42:51Z DEBUG > > >stderr=ldap_initialize( ldap://vm-057.idm.lab.bos.redhat.com ) > > >ldapmodify: wrong attributeType at line 5, entry > > >"cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=idm, > > >dc=lab,dc=bos,dc=redhat,dc=com" > > > > > >2012-06-04T09:42:51Z CRITICAL Failed to load > > >replica-s4u2proxy.ldif: > > >Command '/usr/bin/ldapmodify -h vm-057.idm.lab.bos.redhat.com -v > > >-f /tmp/tmpifHccf -x -D cn=Directory Manager -y /tmp/tmppqaAdV' > > >returned non-zero exit status 247 > > Found and fixed. The issue was in not following RFC2849 when > > specifying > > multiple changetype operations, you need to split their definitions > > by a > > single line with '-' on it. > > > > I squashed the fix back to the original patch. > > > > >But this may be just a symptom of some bigger issue. After the > > >installation finished, DS did not start, it kept reporting > > >Kerberos > > >issues: Does ps -ef|grep slapd show the ns-slapd process running? > > > > > >[04/Jun/2012:05:46:00 -0400] set_krb5_creds - Could not get > > >initial > > >credentials for principal > > >[ldap/vm-057.idm.lab.bos.redhat@idm.lab.bos.redhat.com] in > > >keytab > > >[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see > > >e-text)) > > >[04/Jun/2012:05:46:00 -0400] - slapd started. Listening on All > > >Interfaces port 389 for LDAP requests > > >[04/Jun/2012:05:46:00 -0400] - Listening on All Interfaces port > > >636 for > > >LDAPS requests > > >[04/Jun/2012:05:46:00 -0400] - Listening > > >on /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket for LDAPI requests These last three lines mean the server is up and running. > > >[04/Jun/2012:05:46:00 -0400] slapd_ldap_sasl_interactive_bind - > > >Error: > > >could not perform interactive bind for id [] mech [GSSAPI]: LDAP > > >error > > >-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: > > >Unspecified > > >GSS failure. Minor code may provide more information (Credentials > > >cache > > >file '/tmp/krb5cc_498' not found)) errno 0 (Success) > > >[04/Jun/2012:05:46:00 -0400] slapi_ldap_bind - Error: could not > > >perform > > >interactive bind for id [] mech [GSSAPI]: error -2 (Local error) > > >[04/Jun/2012:05:46:00 -0400] NSMMReplicationPlugin - > > >agmt="cn=meTovm-125.idm.lab.bos.redhat.com" (vm-125:389): > > >Replication > > >bind with GSSAPI auth failed: LDAP error -2 (Local error) > > >(SASL(-1): > > >generic failure: GSSAPI Error: Unspecified GSS failure. Minor > > >code may > > >provide more information (Credentials cache file '/tmp/krb5cc_498' > > >not > > >found)) These error messages should only appear at startup, and should go away once all of the ipa components (especially kdc) are up and running. > > > > > >When I run "ipactl restart", dirsrv started and I was able to > > >kinit. > > Maybe it is timing issue? > > > > > > >4) Patch "Add separate attribute to store trusted domain SID" > > >still has > > >a wrong service part of the principal to be removed (s/ldap/cifs): > > > > > >+dn3 = DN(u'cn=ipa-cifs-delegation-targets', > > >api.env.container_s4u2proxy, self.suffix) > > >+member_principal3 = "ldap/%(fqdn)s@%(realm)s" % > > >dict(fqdn=replica, realm=realm) > > >+ > > > > > >This leaves CIFS entry in the S4U2Proxy configuration even after > > >replica > > >uninstallation. > > Fixed and squashed back to the original patch. > > > > >Btw. these are the packages I use: > > >389-ds-base-1.2.10.4-2.fc17.x86_64 > > >krb5-server-1.10-5.fc17.x86_64 > > >samba4-4.0.0-123alpha21.fc17.x86_64 > > Same here. For me anything newer 1.2.10.4-2 will blow 389-ds. > > > I tested your latest tree against w2k8r2 and was able to create an > validate the trust. So ACK to the functional part. > > bye, > Sumit > > > > > -- > > / Alexander Bokovoy > > > > ___ > > Freeipa-devel mailing list > > Freeipa-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _
Re: [Freeipa-devel] About private ssh host keys in IPA
2012/6/5 Sigbjorn Lie > > > On Fri, June 1, 2012 15:24, Simo Sorce wrote: > > This is about Ticket 1978 (originally rhbz746036). > > > > > > This RFE asks for storing private SSH Host Keys in FreeIPA. > > > > > > We have been triaging this ticket today, and I have to admit I am biased > > toward simply closing down the ticket. > > > > However we want to reach out community and interested parties that > > opened the tick to understand if there are reasons strong enough to > consider implementing it. > > > > The reason I am against this is that in FreeIPA we already provide > > public Key integration. This means that when the host is re-installed > new keys are loaded in IPA > > and clients do not get the obnoxious warning message that keys have > changed, because enrolled > > clients (with the appropriate integration bits) trust FreeIPA so they do > not need to ask the user > > to confirm on a key change. > > > > Storing Private Keys poses various liability issues, in order to be able > > to restore keys you need to give access to those keys to an admin, as > there is no other way to > > authenticate just the host itself (it was just blown away and > reinstalled). This means any admin > > account that can perform reinstalls need to have access to *read* > private keys out of LDAP, which > > means that A) The central tenet of Asymetric authentication is that > private keys > > are 'private'. B) keys are readable from LDAP to some accounts, any > slight error in > > ACIs would risk exposing all private keys. > > C) most probably low level (junior admin) accounts will have read access > > to pretty much all private keys, because those admins are the one tasked > with re-installs. However > > those admins are also the ones less trusted, yet by giving them access > to private keys they are > > enabled to perform MITM attacks against pretty much any of the machines > managed by FreeIPA. > > > > > > For these reasons I am against storing SSH Private Keys. I would like to > > know what are the reasons to instead implement this feature and the > security considerations around > > those reasons. > >> From my point of view the balance between feature vs security issues > >> > > trips in disfavor of implementing the feature but I am willing to be > convinced otherwise if there > > are good reasons to, and security issues can be properly addressed with > some clever scheme. > > > > > I think there has been some confusion here. What I was looking for was a > way to prevent the users > from receiving a message when ssh'ing into a host that's been reinstalled, > that the host's key has > changed. > > I believe will become availabe in the future version IPA 2.2 / RHEL 6.3? > So what you're looking for is an automatic deployment of known_hosts in a centralised way (/etc/ssh) each time a new machine is deployed in an IPA domain ? Regards, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0057 Skip the fix_replica_memberof update plugin for non-root users
Petr Viktorin wrote: On 06/05/2012 03:00 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 06/05/2012 10:06 AM, Martin Kosek wrote: On Mon, 2012-06-04 at 11:51 -0400, Simo Sorce wrote: On Mon, 2012-06-04 at 17:22 +0200, Petr Viktorin wrote: An update plugin needed root privileges, and aborted the update if an ordinary user user ran it. With this patch the plugin is skipped with a warning in that case. https://fedorahosted.org/freeipa/ticket/2621 Hi Petr, I am not sure I like the proposed solution. If there is a legitimate reason to run this plugin as non-root (eg admin user) then you should change the connection part to try to use GSSAPI auth over ldap when non-root, not just throw a warning. If there is no reason for anyone but root to run this script then we should just abort if not root IMO. Simo. I would keep this script runable for root users only. Regularly, this should not be run manually but as a part of RPM update which is done by root. It is being run manually only when something is broken anyway and I am not convinced that non-root users should be involved in such recovery. Martin Thanks for the advice. The attached patch only allows root to run ipa-ldap-updater. NACK. It is very handy for developers to be able to run ipa-ldap-updater to test update files. rob Developers can run it as root, I don't see a problem here. I'd really rather not. This does nothing requiring root permissions, it's all done over LDAP. I'd rather trade not running some plugins than always requiring root. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0057 Skip the fix_replica_memberof update plugin for non-root users
On 06/05/2012 03:00 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 06/05/2012 10:06 AM, Martin Kosek wrote: On Mon, 2012-06-04 at 11:51 -0400, Simo Sorce wrote: On Mon, 2012-06-04 at 17:22 +0200, Petr Viktorin wrote: An update plugin needed root privileges, and aborted the update if an ordinary user user ran it. With this patch the plugin is skipped with a warning in that case. https://fedorahosted.org/freeipa/ticket/2621 Hi Petr, I am not sure I like the proposed solution. If there is a legitimate reason to run this plugin as non-root (eg admin user) then you should change the connection part to try to use GSSAPI auth over ldap when non-root, not just throw a warning. If there is no reason for anyone but root to run this script then we should just abort if not root IMO. Simo. I would keep this script runable for root users only. Regularly, this should not be run manually but as a part of RPM update which is done by root. It is being run manually only when something is broken anyway and I am not convinced that non-root users should be involved in such recovery. Martin Thanks for the advice. The attached patch only allows root to run ipa-ldap-updater. NACK. It is very handy for developers to be able to run ipa-ldap-updater to test update files. rob Developers can run it as root, I don't see a problem here. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 272-273 Add service membership to host objects
This set of patches
1) Adds a support for uni-directional remote membership to baseldap
plugin (like service->host membership in service managedby attribute) -
patch 272
2) Adds a support for service->host membership to host plugin using the
new interface - patch 273
Martin
>From a1e3928f4d747c33fde1b8461455fe9cb2dcb64c Mon Sep 17 00:00:00 2001
From: Martin Kosek
Date: Tue, 5 Jun 2012 13:31:22 +0200
Subject: [PATCH 1/2] Add global support for remote attribute members
Our baseldap plugin already supports automated processing of
physical attribute members (e.g. member, managedby attributes) present
in LDAPObject, their modification or searching. This does not work
for uni-directional relationships, where the member attribute is only
present on the remote LDAP object and not in current LDAP objects,
e.g. virtual "managing" attribute with all hosts that current host
manages.
There was already a partial support for this type of uni-directional
membership in the aforementioned "managing" attribute. This patch
generalizes current code and creates a support for this type of
membership in baseldap plugin so that LDAP objects just have
to define a remote object and attribute name to add support for such
membership. This type of membership is printed only with --all
as it is expensive due to additional LDAP searches.
Tests for this type of memberships are already included in hosts
plugin unit tests.
https://fedorahosted.org/freeipa/ticket/2316
---
ipalib/plugins/baseldap.py | 186 ++--
ipalib/plugins/host.py | 84 ++--
2 files changed, 153 insertions(+), 117 deletions(-)
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 93852a2dd8bf4dd89d7cda780898f96b81f648c4..647eba6d97b65e931a6fe28643950a60ec43da5f 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -466,7 +466,12 @@ class LDAPObject(Object):
# set rdn_attribute only if RDN attribute differs from primary key!
rdn_attribute = ''
uuid_attribute = ''
+# member ettributes stored in LDAP objects
attribute_members = {}
+# virtual member attributes computed from remote physical member attribute
+# format: (remote LDAP object name, remote LDAP object attribute refering to
+# this object)
+remote_members = {}
rdn_is_primary_key = False # Do we need RDN change to do a rename?
password_attributes = []
# Can bind as this entry (has userPassword or krbPrincipalKey)
@@ -551,12 +556,32 @@ class LDAPObject(Object):
oc = map(lambda x:x.lower(),classes)
return objectclass.lower() in oc
-def convert_attribute_members(self, entry_attrs, *keys, **options):
-if options.get('raw', False):
-return
-for attr in self.attribute_members:
+def get_remote_attribute_members(self, entry_attrs, object_dn):
+ldap = self.backend
+
+for attr, objects in self.remote_members.iteritems():
+remote_dns = []
+for object_name, object_attr in objects:
+filter = '%s=%s' % (object_attr, object_dn)
+container_dn = self.api.Object[object_name].container_dn
+
+try:
+(found_objects, truncated) = ldap.find_entries(base_dn=container_dn,
+ filter=filter, attrs_list=[])
+
+remote_dns.extend(found_object[0] for found_object in found_objects)
+except errors.NotFound:
+pass
+
+if remote_dns:
+entry_attrs[attr] = remote_dns
+
+return objects
+
+def convert_attribute_members(self, entry_attrs):
+def convert_attribute_member(attr, objects):
for member in entry_attrs.setdefault(attr, []):
-for ldap_obj_name in self.attribute_members[attr]:
+for ldap_obj_name in objects:
ldap_obj = self.api.Object[ldap_obj_name]
if member.find(ldap_obj.container_dn) > 0:
new_attr = '%s_%s' % (attr, ldap_obj.name)
@@ -565,6 +590,12 @@ class LDAPObject(Object):
)
del entry_attrs[attr]
+for attr, objects in self.attribute_members.iteritems():
+convert_attribute_member(attr, objects)
+for attr, objects in self.remote_members.iteritems():
+object_names = [object[0] for object in objects]
+convert_attribute_member(attr, object_names)
+
def get_password_attributes(self, ldap, dn, entry_attrs):
"""
Search on the entry to determine if it has a password or
@@ -608,8 +639,8 @@ class LDAPObject(Object):
json_friendly_attributes = (
'parent_object', 'container_dn', 'object_name', 'object_name_plural',
'object_class', 'object_class_config', 'default_attributes', 'label', 'label_singular',
-'hidden_attributes', 'uuid_at
Re: [Freeipa-devel] About private ssh host keys in IPA
On Fri, June 1, 2012 15:24, Simo Sorce wrote: > This is about Ticket 1978 (originally rhbz746036). > > > This RFE asks for storing private SSH Host Keys in FreeIPA. > > > We have been triaging this ticket today, and I have to admit I am biased > toward simply closing down the ticket. > > However we want to reach out community and interested parties that > opened the tick to understand if there are reasons strong enough to consider > implementing it. > > The reason I am against this is that in FreeIPA we already provide > public Key integration. This means that when the host is re-installed new > keys are loaded in IPA > and clients do not get the obnoxious warning message that keys have changed, > because enrolled > clients (with the appropriate integration bits) trust FreeIPA so they do not > need to ask the user > to confirm on a key change. > > Storing Private Keys poses various liability issues, in order to be able > to restore keys you need to give access to those keys to an admin, as there > is no other way to > authenticate just the host itself (it was just blown away and reinstalled). > This means any admin > account that can perform reinstalls need to have access to *read* private > keys out of LDAP, which > means that A) The central tenet of Asymetric authentication is that private > keys > are 'private'. B) keys are readable from LDAP to some accounts, any slight > error in > ACIs would risk exposing all private keys. > C) most probably low level (junior admin) accounts will have read access > to pretty much all private keys, because those admins are the one tasked with > re-installs. However > those admins are also the ones less trusted, yet by giving them access to > private keys they are > enabled to perform MITM attacks against pretty much any of the machines > managed by FreeIPA. > > > For these reasons I am against storing SSH Private Keys. I would like to > know what are the reasons to instead implement this feature and the security > considerations around > those reasons. >> From my point of view the balance between feature vs security issues >> > trips in disfavor of implementing the feature but I am willing to be > convinced otherwise if there > are good reasons to, and security issues can be properly addressed with some > clever scheme. > I think there has been some confusion here. What I was looking for was a way to prevent the users from receiving a message when ssh'ing into a host that's been reinstalled, that the host's key has changed. I believe will become availabe in the future version IPA 2.2 / RHEL 6.3? Regards, Siggi ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0057 Skip the fix_replica_memberof update plugin for non-root users
Petr Viktorin wrote: On 06/05/2012 10:06 AM, Martin Kosek wrote: On Mon, 2012-06-04 at 11:51 -0400, Simo Sorce wrote: On Mon, 2012-06-04 at 17:22 +0200, Petr Viktorin wrote: An update plugin needed root privileges, and aborted the update if an ordinary user user ran it. With this patch the plugin is skipped with a warning in that case. https://fedorahosted.org/freeipa/ticket/2621 Hi Petr, I am not sure I like the proposed solution. If there is a legitimate reason to run this plugin as non-root (eg admin user) then you should change the connection part to try to use GSSAPI auth over ldap when non-root, not just throw a warning. If there is no reason for anyone but root to run this script then we should just abort if not root IMO. Simo. I would keep this script runable for root users only. Regularly, this should not be run manually but as a part of RPM update which is done by root. It is being run manually only when something is broken anyway and I am not convinced that non-root users should be involved in such recovery. Martin Thanks for the advice. The attached patch only allows root to run ipa-ldap-updater. NACK. It is very handy for developers to be able to run ipa-ldap-updater to test update files. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0057 Skip the fix_replica_memberof update plugin for non-root users
Martin Kosek wrote: On Mon, 2012-06-04 at 11:51 -0400, Simo Sorce wrote: On Mon, 2012-06-04 at 17:22 +0200, Petr Viktorin wrote: An update plugin needed root privileges, and aborted the update if an ordinary user user ran it. With this patch the plugin is skipped with a warning in that case. https://fedorahosted.org/freeipa/ticket/2621 Hi Petr, I am not sure I like the proposed solution. If there is a legitimate reason to run this plugin as non-root (eg admin user) then you should change the connection part to try to use GSSAPI auth over ldap when non-root, not just throw a warning. If there is no reason for anyone but root to run this script then we should just abort if not root IMO. Simo. I would keep this script runable for root users only. Regularly, this should not be run manually but as a part of RPM update which is done by root. It is being run manually only when something is broken anyway and I am not convinced that non-root users should be involved in such recovery. I'd agree if root was actually needed for this. It is only needed because we're using ldapi and relying on autobind. The real trick is that this doesn't use GSSAPI. Many updates require the DM password. So the question becomes, do we have the DM password available in the plugin to bind if we're not running a root? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 147 Set network.http.sendRefererHeader to 2 on browser config
On 06/05/2012 05:01 AM, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/29/2012 11:29 PM, Rob Crittenden wrote:
Petr Vobornik wrote:
IPA web UI isn't functional when browser doesn't send http headers.
This patch adds a functionality which sets Firefox
network.http.sendRefererHeader configuration option to value '2' which
enables it.
Possible values:
http://kb.mozillazine.org/Network.http.sendRefererHeader
https://fedorahosted.org/freeipa/ticket/2778
Should we also add a message when referer is missing to check this
setting in about:config?
I'm not sure what you have in mind. We set the referer option so why
would user check it afterwards?
Yes the ticket was about checking the option but: If user is configuring
the browser he wants the browser configured. So we should set all
options which are required. This is one of them. We have not been
notifying the user what was set, so I didn't add such notification for
this option now as well.
We might want to notify the user what options were changed but it's not
the topic of this ticket.
I was thinking more for already configured browsers who then later mess
with this value. It fails in a very non-obvious way.
rob
I'm attaching a patch which slightly changes the displayed error message
from:
Missing or invalid HTTP Referer, missing
to:
Missing HTTP referer.
You have to configure your browser to send HTTP referer header.
Also I think we should document how to set it manually. We already have
documentation for the rest of browser configuration.
--
Petr Vobornik
From dbe3075e2245caa4be3a3d1ddf634c54b8eb2633 Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Tue, 5 Jun 2012 14:28:44 +0200
Subject: [PATCH] Custom Web UI error message for IPA error 911
Error message for IPA error 911 is not very clear for end users.
This patch changes the message and adds an advice how to get rid of the error.
https://fedorahosted.org/freeipa/ticket/2778
---
install/ui/ipa.js| 10 ++
install/ui/jquery.ordered-map.js | 17 -
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/install/ui/ipa.js b/install/ui/ipa.js
index 648fcfc31e1f017aeecd597189b5d4a9789194ae..21e258cee5adf925d85665a71db0b96abdb18165 100644
--- a/install/ui/ipa.js
+++ b/install/ui/ipa.js
@@ -434,6 +434,9 @@ IPA.command = function(spec) {
that.retry = typeof spec.retry == 'undefined' ? true : spec.retry;
that.error_message = spec.error_message || IPA.get_message('dialogs.batch_error_message', 'Some operations failed.');
+that.error_messages = $.ordered_map({
+911: 'Missing HTTP referer. You have to configure your browser to send HTTP referer header.'
+});
that.get_command = function() {
return (that.entity ? that.entity+'_' : '') + that.method;
@@ -563,6 +566,13 @@ IPA.command = function(spec) {
};
}
+// custom messages for set of codes
+var error_msg = that.error_messages.get(error_thrown.code);
+if (error_msg) {
+error_msg = error_msg.replace('${message}', error_thrown.message);
+error_thrown.message = error_msg;
+}
+
if (that.retry) {
dialog_open.call(this, xhr, text_status, error_thrown);
diff --git a/install/ui/jquery.ordered-map.js b/install/ui/jquery.ordered-map.js
index 7c0f3fadce9c5fde68540f1f3d585cf35af1b3ee..64cad6e0346c4281b680d523e17c550819171319 100755
--- a/install/ui/jquery.ordered-map.js
+++ b/install/ui/jquery.ordered-map.js
@@ -18,7 +18,7 @@
* along with this program. If not, see
Re: [Freeipa-devel] [PATCH] 492 Add options to reduce writes from KDC
On Mon, 2012-06-04 at 22:59 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > The original ldap driver we used up to 2.2 had 2 options admins could > > set to limit the amount of writes to the database on certain auditing > > related operations. > > In particular disable_last_success is really important to reduce the > > load on database servers. > > > > I have implemented ticket #2734 with a little twist. Instead of adding > > local options in krb5.conf I create global options in the LDAP tree, so > > that all KDCs in the domain have the same configuration. > > > > The 2 new options can be set in ipaConfigString attribute of the > > cn=ipaConfig object under cn=etc,$SUFFIX > > > > These are: > > KDC:Disable Last Success > > KDC:Disable Lockout > > > > The first string if set will disable updating the krbLastSuccessfulAuth > > field in the service/user entry. > > The second one will prevent changing any of the Lockout related fields > > and will effectively disable lockout policies. > > > > I think we may want to set the first one by default in future. > > The last successful auth field is not very interesting in general and is > > cause for a lot of writes that pressure a lot the LDAP server and get > > replicated everywhere with a storm multiplier effect we'd like to avoid. > > > > The lockout one instead happen only when there are failed authentication > > attempt, this means it never happens when keytabs are used for example. > > And even with users it should happen rarely enough that traking lockouts > > by default make leaving these writes on by default is a good tradeoff. > > > > Note that simply setting the lockout policy to never lockout is *not* > > equivalent to setting KDC:Disable Lockout, as it does not prevent writes > > to the database. > > > > I've tested setting KDC:Disable Last Success and it effectively prevent > > MOD operation from showing up in the server access log. > > > > Any change to these configuration options requires a reconnection from > > the KDC to the LDAP server, the simplest way to cause that is to restart > > the KDC service. > > > > Simo. > > In ipadb_get_global_configs() should there be a call to LOG_OOM()? > > Also, if ipadb_simple_search() or ipadb_get_global_configs() fails > should we log the result code when non-zero? Well this code runs in the KDC, not in DIRSRV so LOG_OOM() wouldn't work. Perhaps we should add KDC_LOG() macros, but that would be a separate task imo. 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] 0058 Prevent deletion of the last admin
Raise an error when trying to delete the last user from the 'admins'
group
The 'admin' group name seems like something that shouldn't be hardcoded,
but that's how it's done in the webui and some of our ACIs, and I don't
see another solution short of adding a new attribute.
https://fedorahosted.org/freeipa/ticket/2564
--
Petr³
From 8ae8bf5b0c05caa828eb342c0c24a16be38adae8 Mon Sep 17 00:00:00 2001
From: Petr Viktorin
Date: Wed, 23 May 2012 05:44:53 -0400
Subject: [PATCH] Prevent deletion of the last admin
Raise an error when trying to delete the last user from the 'admins'
group
https://fedorahosted.org/freeipa/ticket/2564
---
ipalib/errors.py | 16 +
ipalib/plugins/user.py|9 ++--
tests/test_xmlrpc/test_user_plugin.py | 41 +
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/ipalib/errors.py b/ipalib/errors.py
index df4ab4167cb5eee1ab940518746bf5c4109a009f..7c7ab575c2a510889adb3a0893c905e40e1f6d8b 100644
--- a/ipalib/errors.py
+++ b/ipalib/errors.py
@@ -1575,6 +1575,22 @@ class DependentEntry(ExecutionError):
format = _('%(key)s cannot be deleted because %(label)s %(dependent)s requires it')
+class LastMemberError(ExecutionError):
+"""
+**4308** Raised when an entry being deleted is last member of an admins group
+
+For example:
+>>> raise LastMemberError(key=u'admin', label=u'group', container=u'admins')
+Traceback (most recent call last):
+ ...
+LastMemberError: admin cannot be deleted because it is the last member of group admins
+
+"""
+
+errno = 4308
+format = _('%(key)s cannot be deleted because it is the last member of %(label)s %(container)s')
+
+
##
# 5000 - 5999: Generic errors
diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index b48e68022c88f5b5f777c8d10e0775d566fd9480..7e98bba4c48436588ff3baffad538a426b9f5edb 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -544,8 +544,13 @@ class user_del(LDAPDelete):
msg_summary = _('Deleted user "%(value)s"')
-def post_callback(self, ldap, dn, *keys, **options):
-return True
+def pre_callback(self, ldap, dn, *keys, **options):
+protected_group_name = u'admins'
+result = api.Command.group_show(protected_group_name)
+if result['result'].get('member_user', []) == [keys[-1]]:
+raise errors.LastMemberError(key=keys[-1], label=_(u'group'),
+container=protected_group_name)
+return dn
api.register(user_del)
diff --git a/tests/test_xmlrpc/test_user_plugin.py b/tests/test_xmlrpc/test_user_plugin.py
index 4b2be5c325ab8d5a73a62f9c979ca5f40f3498bb..355a4cd1a758885c50b8f2450444cff23fd6 100644
--- a/tests/test_xmlrpc/test_user_plugin.py
+++ b/tests/test_xmlrpc/test_user_plugin.py
@@ -1330,4 +1330,45 @@ class test_user(Declarative):
),
expected=lambda x: True,
),
+
+dict(
+desc='Try to remove the admin user',
+command=('user_del', [u'admin'], {}),
+expected=errors.LastMemberError(key=u'admin', label=u'group',
+container='admins'),
+),
+
+dict(
+desc='Add %r to the admins group' % user2,
+command=('group_add_member', [u'admins'], dict(user=user2)),
+expected=dict(
+completed=1,
+failed=dict(
+member=dict(
+group=tuple(),
+user=tuple(),
+),
+),
+result={
+'dn': lambda x: DN(x) == \
+DN(('cn', 'admins'), ('cn', 'groups'),
+('cn', 'accounts'), api.env.basedn),
+'member_user': [u'admin', user2],
+'gidnumber': [fuzzy_digits],
+'cn': [u'admins'],
+'description': [u'Account administrators group'],
+},
+),
+),
+
+dict(
+desc='Delete %r' % user2,
+command=('user_del', [user2], {}),
+expected=dict(
+result=dict(failed=u''),
+summary=u'Deleted user "%s"' % user2,
+value=user2,
+),
+),
+
]
--
1.7.10.2
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0042-0048 AD trusts support (master)
On Mon, Jun 04, 2012 at 03:32:36PM +0300, Alexander Bokovoy wrote: > On Mon, 04 Jun 2012, Martin Kosek wrote: > >I did another round of testing and this is what I found so far: > > > >1) freeipa.spec.in was missing python-crypto BuildRequires (you fixed > >that) > > > >2) Unit tests need to be updated, currently there is about a dozen test > >case errors, e.g. extra ipakrbprincipalalias attribute in services or > >new ipakrbprincipal objectclass for hosts > Ok, will fix. > > >3) Replication did not work too well for me this time. > >ipa-replica-install reported just one issue during installation process: > > > >2012-06-04T09:42:51Z DEBUG [24/30]: enabling S4U2Proxy delegation > >2012-06-04T09:42:51Z DEBUG args=/usr/bin/ldapmodify -h > >vm-057.idm.lab.bos.redhat.com -v -f /tmp/ tmpifHccf -x -D > >cn=Directory Manager -y /tmp/tmppqaAdV > >2012-06-04T09:42:51Z DEBUG stdout= > >2012-06-04T09:42:51Z DEBUG > >stderr=ldap_initialize( ldap://vm-057.idm.lab.bos.redhat.com ) > >ldapmodify: wrong attributeType at line 5, entry > >"cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=idm, > >dc=lab,dc=bos,dc=redhat,dc=com" > > > >2012-06-04T09:42:51Z CRITICAL Failed to load replica-s4u2proxy.ldif: > >Command '/usr/bin/ldapmodify -h vm-057.idm.lab.bos.redhat.com -v > >-f /tmp/tmpifHccf -x -D cn=Directory Manager -y /tmp/tmppqaAdV' > >returned non-zero exit status 247 > Found and fixed. The issue was in not following RFC2849 when specifying > multiple changetype operations, you need to split their definitions by a > single line with '-' on it. > > I squashed the fix back to the original patch. > > >But this may be just a symptom of some bigger issue. After the > >installation finished, DS did not start, it kept reporting Kerberos > >issues: > > > >[04/Jun/2012:05:46:00 -0400] set_krb5_creds - Could not get initial > >credentials for principal > >[ldap/vm-057.idm.lab.bos.redhat@idm.lab.bos.redhat.com] in keytab > >[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) > >[04/Jun/2012:05:46:00 -0400] - slapd started. Listening on All > >Interfaces port 389 for LDAP requests > >[04/Jun/2012:05:46:00 -0400] - Listening on All Interfaces port 636 for > >LDAPS requests > >[04/Jun/2012:05:46:00 -0400] - Listening > >on /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket for LDAPI requests > >[04/Jun/2012:05:46:00 -0400] slapd_ldap_sasl_interactive_bind - Error: > >could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > >-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > >GSS failure. Minor code may provide more information (Credentials cache > >file '/tmp/krb5cc_498' not found)) errno 0 (Success) > >[04/Jun/2012:05:46:00 -0400] slapi_ldap_bind - Error: could not perform > >interactive bind for id [] mech [GSSAPI]: error -2 (Local error) > >[04/Jun/2012:05:46:00 -0400] NSMMReplicationPlugin - > >agmt="cn=meTovm-125.idm.lab.bos.redhat.com" (vm-125:389): Replication > >bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): > >generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may > >provide more information (Credentials cache file '/tmp/krb5cc_498' not > >found)) > > > >When I run "ipactl restart", dirsrv started and I was able to kinit. > Maybe it is timing issue? > > > >4) Patch "Add separate attribute to store trusted domain SID" still has > >a wrong service part of the principal to be removed (s/ldap/cifs): > > > >+dn3 = DN(u'cn=ipa-cifs-delegation-targets', > >api.env.container_s4u2proxy, self.suffix) > >+member_principal3 = "ldap/%(fqdn)s@%(realm)s" % > >dict(fqdn=replica, realm=realm) > >+ > > > >This leaves CIFS entry in the S4U2Proxy configuration even after replica > >uninstallation. > Fixed and squashed back to the original patch. > > >Btw. these are the packages I use: > >389-ds-base-1.2.10.4-2.fc17.x86_64 > >krb5-server-1.10-5.fc17.x86_64 > >samba4-4.0.0-123alpha21.fc17.x86_64 > Same here. For me anything newer 1.2.10.4-2 will blow 389-ds. I tested your latest tree against w2k8r2 and was able to create an validate the trust. So ACK to the functional part. bye, Sumit > > -- > / Alexander Bokovoy > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0057 Skip the fix_replica_memberof update plugin for non-root users
On 06/05/2012 10:06 AM, Martin Kosek wrote:
On Mon, 2012-06-04 at 11:51 -0400, Simo Sorce wrote:
On Mon, 2012-06-04 at 17:22 +0200, Petr Viktorin wrote:
An update plugin needed root privileges, and aborted the update if an
ordinary user user ran it.
With this patch the plugin is skipped with a warning in that case.
https://fedorahosted.org/freeipa/ticket/2621
Hi Petr,
I am not sure I like the proposed solution.
If there is a legitimate reason to run this plugin as non-root (eg admin
user) then you should change the connection part to try to use GSSAPI
auth over ldap when non-root, not just throw a warning.
If there is no reason for anyone but root to run this script then we
should just abort if not root IMO.
Simo.
I would keep this script runable for root users only. Regularly, this
should not be run manually but as a part of RPM update which is done by
root. It is being run manually only when something is broken anyway and
I am not convinced that non-root users should be involved in such
recovery.
Martin
Thanks for the advice. The attached patch only allows root to run
ipa-ldap-updater.
--
Petr³
From a4069362d5fd85db58a8dfc75c3d210bec11a361 Mon Sep 17 00:00:00 2001
From: Petr Viktorin
Date: Tue, 5 Jun 2012 04:33:30 -0400
Subject: [PATCH] Only allow root to run ipa-ldap-updater
This script is an internal tool not intended to be executed by
end-users. We only run it when installing/upgrading.
Therefore there's no reason to allow non-root users to run it.
https://fedorahosted.org/freeipa/ticket/2621
---
install/tools/ipa-ldap-updater | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/install/tools/ipa-ldap-updater b/install/tools/ipa-ldap-updater
index bd2233a94241c28375b29cc10d60908238b8f176..73e5d1680eb8344bb09de18f1409acb1161be44e 100755
--- a/install/tools/ipa-ldap-updater
+++ b/install/tools/ipa-ldap-updater
@@ -87,10 +87,10 @@ def main():
safe_options, options, args = parse_options()
-if os.getegid() == 0:
-installutils.check_server_configuration()
-elif not os.path.exists('/etc/ipa/default.conf'):
-sys.exit("IPA is not configured on this system.")
+if os.getegid() != 0:
+sys.exit("Must be root to run this script")
+
+installutils.check_server_configuration()
dirman_password = ""
if options.password:
@@ -124,8 +124,6 @@ def main():
updates = None
if options.upgrade:
-if os.getegid() != 0:
-sys.exit('Upgrade can only be done as root')
root_logger.debug('%s was invoked with arguments %s and options: %s' % (sys.argv[0], args, safe_options))
realm = krbV.default_context().default_realm
upgrade = IPAUpgrade(realm, files, live_run=not options.test)
--
1.7.10.2
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 272 Fix dnszone-mod --forwader option help string
Pushed under the one-liner rule.
---
Help should not point to global forwarders but rather to per-zone
conditional forwarders.
https://fedorahosted.org/freeipa/ticket/2717
>From a39f4d0bebc1ff1d63099ca18fef3a52c595b6de Mon Sep 17 00:00:00 2001
From: Martin Kosek
Date: Tue, 5 Jun 2012 10:42:43 +0200
Subject: [PATCH] Fix dnszone-mod --forwader option help string
Help should not point to global forwarders but rather to per-zone
conditional forwarders.
https://fedorahosted.org/freeipa/ticket/2717
---
ipalib/plugins/dns.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index a482627946537a697491b7761431bcf70f2c0639..0f1014caed58105334a3eb5590329e8fa749de5b 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -1661,7 +1661,7 @@ class dnszone(LDAPObject):
_validate_bind_forwarder,
cli_name='forwarder',
label=_('Zone forwarders'),
-doc=_('A list of global forwarders. A custom port can be specified ' \
+doc=_('A list of per-zone forwarders. A custom port can be specified '
'for each forwarder using a standard format "IP_ADDRESS port PORT"'),
csv=True,
),
--
1.7.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0057 Skip the fix_replica_memberof update plugin for non-root users
On Mon, 2012-06-04 at 11:51 -0400, Simo Sorce wrote: > On Mon, 2012-06-04 at 17:22 +0200, Petr Viktorin wrote: > > An update plugin needed root privileges, and aborted the update if an > > ordinary user user ran it. > > With this patch the plugin is skipped with a warning in that case. > > > > https://fedorahosted.org/freeipa/ticket/2621 > > Hi Petr, > I am not sure I like the proposed solution. > > If there is a legitimate reason to run this plugin as non-root (eg admin > user) then you should change the connection part to try to use GSSAPI > auth over ldap when non-root, not just throw a warning. > > If there is no reason for anyone but root to run this script then we > should just abort if not root IMO. > > Simo. > I would keep this script runable for root users only. Regularly, this should not be run manually but as a part of RPM update which is done by root. It is being run manually only when something is broken anyway and I am not convinced that non-root users should be involved in such recovery. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 271 Fill new DNS zone update policy by default
On Tue, 2012-06-05 at 14:44 +0930, William Brown wrote: > > I think the example should be something like: > > > > Modify the zone to allow dynamic updates for hosts own records in > > realm EXAMPLE.COM: > >ipa dnszone-mod example.com --dynamic-update=TRUE > > > > This is the equivalent of: > >ipa dnszone-mod example.com --dynamic-update=TRUE \\ > > --update-policy="grant EXAMPLE.COM krb5-self * A; grant > > EXAMPLE.COM krb5-self * ;" > > > > What about reverse zones? With the patch I just pushed is the update policy for reverse zone automatically generated as well: # ipa dnszone-add 3.2.1.in-addr.arpa. --name-server=ns.example.com Administrator e-mail address [hostmaster.3.2.1.in-addr.arpa.]: Zone name: 3.2.1.in-addr.arpa. Authoritative nameserver: ns.example.com. Administrator e-mail address: hostmaster.3.2.1.in-addr.arpa. SOA serial: 2012060501 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant EXAMPLE.COM krb5-subdomain 3.2.1.in-addr.arpa. PTR; Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none; # ipa dnszone-mod 3.2.1.in-addr.arpa. --dynamic-update=TRUE Zone name: 3.2.1.in-addr.arpa. Authoritative nameserver: ns.example.com. Administrator e-mail address: hostmaster.3.2.1.in-addr.arpa. SOA serial: 2012060501 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Dynamic update: TRUE Allow query: any; Allow transfer: none; With the second change, dynamic updates for the reverse zone are enabled without users having to be knowledgeable about BIND update policy format. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 262-265 Enable psearch by default
On Mon, 2012-06-04 at 23:49 -0400, Rob Crittenden wrote:
> Martin Kosek wrote:
> > On Fri, 2012-05-25 at 17:14 +0200, Martin Kosek wrote:
> >> On Fri, 2012-05-25 at 09:25 -0400, Rob Crittenden wrote:
> >>> Martin Kosek wrote:
> This set of patches handles enabling psearch both for new installations
> (patch 263) and upgraded IPA servers.
>
> For upgraded IPA servers I needed to make sure that psearch is not
> enabled for every IPA package update, but at most once, when a user
> updates to IPA with this patch for the first time (patch 264). This is
> enabled by a new State store located in /var/lib/ipa/sysupgrade (patch
> 262).
>
> I also improved the way we handled SELinux sebool updates (patch 265),
> this can make ipa-upgradeconfig to finish in 0.4 seconds and not in 150
> seconds as previously. Details are in the patches.
>
> Martin
> >>>
> >>> 262:
> >>> The sysupgrade directory isn't created by the RPM install:
> >>>
> >>> mkdir -p %{buildroot}/%{_localstatedir}/cache/ipa/sysupgrade
> >>
> >> Fixed.
> >>
> >>>
> >>> 263:
> >>>
> >>> It looks like zone_refresh is simply disabled in bindinstance.py, why
> >>> not remove it completely?
> >>
> >> zone_refresh is used by bindinstance.py. ipa-server-install or
> >> ipa-dns-install may be configured to use zone refresh instead of
> >> persistent search mechanism to update the zones (e.g. --zone-refresh
> >> 30).
> >>
> >>>
> >>> 264:
> >>>
> >>> Small nit, worth doing case-insensitive compare of psearch enabled status?
> >>
> >> Petr2 told me that arg value for boolean configuration option is
> >> case-insensitive, so we can do that - fixed.
> >>
> >>>
> >>> We're updating named.conf in place so I don't know that we need to reset
> >>> permissions. It at least shouldn't get modified by the write.
> >>
> >> Right, I was being too defensive. I removed the check.
> >>
> >> I made the upgrade more robust, now it won't crash for example when
> >> named.conf does not exist. I also made sure the upgrade script works
> >> correctly when the IPA is configured without DNS.
> >>
> >> Martin
> >
> > I rebased the patches for current master. I also slightly reworked patch
> > 265, the error message printed in case of an unsuccessful setsebool was
> > not printed right.
> >
> > Martin
>
> Trailing whitespace in 264:
>
> # git am /tmp/freeipa-mkosek-264-3-enable-psearch-on-upgrades.patch
> Applying: Enable psearch on upgrades
> /home/rcrit/redhat/freeipa-nossh/.git/rebase-apply/patch:108: trailing
> whitespace.
> root_logger.error('Cannot update connections in %s:
> %s',
> warning: 1 line adds whitespace errors.
Fixed.
>
> I don't think the DNS detection is adequate in 264, testing for
> named.conf is not enough. What if someone is running a non-IPA DNS
> server on the box?
I assume you are referring to this line:
+if not bindinstance.named_conf_exists():
It checks both if the named.conf exists + if it has bind-dyndb-ldap
configured for IPA:
if line.startswith('dynamic-db "ipa"'):
>
> I know that I've recently done similar config changes but in 265 is
> using line.startswith() going to be fragile?
I assume you mean patch 264. This should be OK - user would need to mess
with the configuration generated by our install scripts to break it. But
in this case, other regex-es would fail too. I did not want to get too
wild with regex-es to keep it simple and safe. The worst case scenario
should be that named.conf is not updated and psearch is not turned on.
>
> In 266 I'd merge in the ipa-upgradeconfig change into 265 or some other
> patch.
I assume you mean patch 265. I had this change moved to 264 right after
I sent the patches :-)
>
> In the 'for setting, state' loop should it be catching a
> CalledProcessException rather than raw Exception? I think that is all
> that should be raised there.
Right, fixed.
>
> I did an upgrade and it seemed to work ok, ended up with these scary
> messages in /var/log/messages:
>
> Jun 4 23:39:17 localhost named[18753]: LDAP error: Can't contact LDAP
> server
> Jun 4 23:39:17 localhost named[18753]: connection to the LDAP server
> was lost
> Jun 4 23:39:17 localhost named[18753]: bind to LDAP server failed:
> Can't contact LDAP server
> Jun 4 23:39:17 localhost named[18753]: ldap_psearch_watcher failed to
> handle LDAP connection error. Reconnection in 60s
> Jun 4 23:39:17 localhost named[18753]: LDAP error: Can't contact LDAP
> server
> Jun 4 23:39:17 localhost named[18753]: connection to the LDAP server
> was lost
> Jun 4 23:39:17 localhost named[18753]: bind to LDAP server failed:
> Can't contact LDAP server
> Jun 4 23:39:17 localhost ns-slapd[18798]: [04/Jun/2012:23:39:17 -0400]
> - Information: Non-Secure Port Disabled
> Jun 4 23:40:17 localhost named[18753]: handle_connection_error failed
> to obtain ldap error code
> Jun 4 23:40:17 localhost named[18753]: connection to the LDAP server
> was
