date:20140611

Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile

2014-06-11 Thread Martin Kosek

On 06/10/2014 09:55 AM, Martin Kosek wrote:
 On 06/06/2014 12:50 PM, Jan Cholasta wrote:
...
 Updated patches attached.

 Note that you will need python-nss 0.15 in order to test, you can get a RPM 
 for
 Fedora here: http://koji.fedoraproject.org/koji/buildinfo?buildID=514739.
 
 John, do you think we could build python-nss 0.15 also for Fedora 20? The fix
 incorporated in it is pretty important to warrant bugfix update in bodhi. It
 would also allow FreeIPA 4.0 to be installed on Fedora 20.

John kindly built python-nss also for Fedora 20:
https://admin.fedoraproject.org/updates/python-nss-0.15.0-1.fc20

I did a quick test and parsing SAN still worked fine, so I gave karma. I would
like to ask others who test the library to do the same as karma will be
required for it to move to stable updates repo.

Thanks,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] Update plugins to use Registry API

2014-06-11 Thread Martin Kosek

On 06/10/2014 07:11 PM, Petr Vobornik wrote:
 On 10.6.2014 17:29, Nathaniel McCallum wrote:
 On Tue, 2014-06-10 at 16:45 +0200, Jan Cholasta wrote:
 Hi,

 On 6.6.2014 20:33, Nathaniel McCallum wrote:
 I kept seeing the old plugin registration style when writing/reviewing
 code and I decided to fix it. Attached are patches to update the
 remaining 31 plugins from the old plugin registration style to the new
 style.

 This would be a great starting point for someone new to doing reviews.

 Nathaniel

 I can't imagine a situation in which having these in separate commits
 would be beneficial, so I don't think this really deserves to be split
 among multiple patches.

 My thought was to make it easier to review in small chunks for new
 reviewers. But if we want to do it as a single patch, one is attached.

 Nathaniel

 
 ACK
 
 btw it was easier to review the batch at once.
 
 should we also update the tutorial in ipalib/__init__.py and other comments?
 
 Note that there is quite a lot of `api.register(cls)` calls outside of
 ipalib/plugins dir. IMHO it's OK since it's not a subject of this patch.

Pushed to master: 255cbb49763ff579feed935a5a725fc2b272749c

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] user certificates

2014-06-11 Thread Fraser Tweedale

Hi all,

Use cases are emerging for user certificates in FreeIPA.  Some
include:

- VPN certificates.  A user logs into an IPA domain.  They are not
  connected to a wired network so a background service (SSSD or
  other) acquires a short-lived client certificate for connecting to
  the company VPN (and connects it, thus saving the user some time
  and hassle).

- A DNP3 Smart-Grid user's roles are updated.  A new IEC 62351-8
  certificate must be signed by the CA and provided to the DNP3 to
  be sent to outstations on the network.

There are other use cases for user certificates, e.g. client
authentication for HTTP or other network services.  Perhaps you know
of others - in which case let us know.

Are there any current plans/design documents for implementing user
certificates in FreeIPA?  Or if I'm way off track in my thinking
here, please help me understand how these use cases do or do not
apply to FreeIPA :)

As a side-note: support for different Dogtag profiles in FreeIPA is
prerequisite for this - in fact it is likely that even a single user
may need to acquire certificates with different profiles, for the
different use cases.

Cheers,

Fraser

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 631 webui: fix regression: enabled gid field on group add

2014-06-11 Thread Petr Vobornik


On 10.6.2014 23:10, Endi Sukma Dewata wrote:

On 5/14/2014 9:41 AM, Petr Vobornik wrote:

GID field should be enabled by default since the default group is posix.

Was caused by option_widget_base not properly reporting value change
while
selecting the default value. It has to be notified with delay
otherwise the
event is consumed by FieldBinder.

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


ACK.



Pushed to master: e3840eef09f4a6b1ac3c0a92f5929353a6c9e6b6
--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 591 webui: add idnsSecInlineSigning option to DNS zone details facet

2014-06-11 Thread Petr Vobornik


On 10.6.2014 23:10, Endi Sukma Dewata wrote:

On 4/30/2014 5:28 AM, Petr Vobornik wrote:

Web UI part of pviktori-543

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


ACK.


Pushed to master: 9c97bbd347b89634a844726c5d1f0ef39df4d139
--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile

2014-06-11 Thread Jan Cholasta


On 10.6.2014 09:55, Martin Kosek wrote:

On 06/06/2014 12:50 PM, Jan Cholasta wrote:

On 23.1.2014 14:34, Jan Cholasta wrote:

On 22.1.2014 16:43, Simo Sorce wrote:

On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote:

On 22.1.2014 15:34, Simo Sorce wrote:

On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote:

On 21.1.2014 17:12, Simo Sorce wrote:

Later in the patch you seem to be changing from needing
managedby_host
to needing write access to an entry, I am not sure I understand
why that
was changed. not saying it is necessarily wrong,  but why the
original
check is not right anymore ?


The original check is wrong, see
https://fedorahosted.org/freeipa/ticket/3977#comment:23.

The check in my patch allows SAN only if the requesting host has write
access to all of the SAN services. I'm not entirely sure if this is
right, but even if it is not, I think we should still check for write
access to the SAN services, so that access control can be (partially)
handled by ACIs.


Right, I remembered that comment, but it just says to check the right
object's managed-by, here instead you changed it to check if you can
write the usercertificate.

I guess it is the same *if* there is an ACI that gives write permission
when the host is in the managed-by attribute, is that the reasoning ?


Exactly. The ACIs that allow this by default are named Hosts can manage
service Certificates and kerberos keys and Hosts can manage other host
Certificates and kerberos keys.

I think the check can be extended to users as well, so that requesting
certificate with SAN is allowed only to users which have write access to
the SAN services.


I have done the modification, see attached patches.



Sounds good to me then, thanks for explaining.

The patches also look good, but I would like someone to give them a try
for a formal ack.


OK, thanks.



Bump.

I have added stricter validation of subject alt names as well as certificate
extensions in general to the second patch.


Thanks!


Updated patches attached.

Note that you will need python-nss 0.15 in order to test, you can get a RPM for
Fedora here: http://koji.fedoraproject.org/koji/buildinfo?buildID=514739.


John, do you think we could build python-nss 0.15 also for Fedora 20? The fix
incorporated in it is pretty important to warrant bugfix update in bodhi. It
would also allow FreeIPA 4.0 to be installed on Fedora 20.


Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not work,
because https://fedorahosted.org/freeipa/ticket/4370.


This worked for me, I suspect this is a DS bug. More info in the ticket.

Now back to review of the patch:

210.4: looks ok
234.4:

1) Virtual operation request certificate with subjectaltname should be a
member of Certificate Administrators privilege


OK.




2) I would write Request Certificate With SubjectAltName with with instead
of With. I.e.:
Request Certificate with SubjectAltName


OK.




3) Why is the extension check only enforced for non-hosts?

+if not bind_principal.startswith('host/'):
+for ext in extensions:
+operation = self._allowed_extensions.get(ext)
+if operation:
+self.check_access(operation)

My tricky certmonger request passed:

# ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r
-N cn=`hostname` -K host/`hostname` -D test1.example.com -D test2.example.com
-E mko...@redhat.com

while when I posted the same CSR as privileged user, it was rejected:

$ klist
Ticket cache: KEYRING:persistent:96203:96203
Default principal: f...@idm.lab.eng.brq.redhat.com

$ ipa cert-request --principal test/`hostname` certmonger.csr
ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden


Right, I meant to NACK myself, but you were faster. Fixed.




4) Regular users cannot read Virtual Operations, so even if I assign them a
permission, command is refused:

$ ipa cert-request --principal test/`hostname` openssl.csr
ipa: ERROR: Insufficient access: No such virtual command

I think we will need to create new managed permission Read Virtual Operations
and assign it to Certificate Administrators privilege by default as this
privilege has the virtual operation permissions assigned. Petr3, what is your
take on this?

Otherwise the patch worked well for me, the authorization part looked OK. My
biggest concern was just the host/user differentiation wrt unknown
subjectaltname types.

Martin



Updated patches attached.

--
Jan Cholasta
From 16cdfdee68c39caf00bbc44e881053940592a567 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Thu, 5 Dec 2013 14:34:14 +0100
Subject: [PATCH 1/2] Allow SAN in IPA certificate profile.

https://fedorahosted.org/freeipa/ticket/3977
---
 install/tools/ipa-upgradeconfig |  7 +-
 ipaserver/install/cainstance.py | 51 +
 2 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/install/tools/ipa-upgradeconfig

[Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop

2014-06-11 Thread Tomas Babej

Hi,

As due to possible race conditions, the preop.pin might not be
written in the CS.cfg at the time installer tries to read it.

In case no value for preop.pin was found, retry until timeout
was reached.

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

(applies on ipa-3-0 branch)

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 


From d543e2901f3a4eb49b6e2267901cf9de3a439a43 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 11 Jun 2014 11:06:03 +0200
Subject: [PATCH] cainstance: Read CS.cfg for preop.pin in a loop

As due to possible race conditions, the preop.pin might not be
written in the CS.cfg at the time installer tries to read it.

In case no value for preop.pin was found, retry until timeout
was reached.

https://fedorahosted.org/freeipa/ticket/3382
---
 ipaserver/install/cainstance.py | 47 -
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index 4bf915030b83983323adec043066baa726089493..1048971e37f3ebe279ef8e0db645ae615b570d9a 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -39,7 +39,7 @@ import syslog
 from ipapython import dogtag
 from ipapython.certdb import get_ca_nickname
 from ipapython import certmonger
-from ipalib import pkcs10, x509
+from ipalib import pkcs10, x509, api
 from ipalib import errors
 from ipapython.dn import DN
 import subprocess
@@ -108,20 +108,37 @@ def get_preop_pin(instance_root, instance_name):
 
 filename = instance_root + / + instance_name + /conf/CS.cfg
 
-# read the config file and get the preop pin
-try:
-f=open(filename)
-except IOError, e:
-root_logger.error(Cannot open configuration file. + str(e))
-raise e
-data = f.read()
-data = data.split('\n')
-pattern = re.compile(preop.pin=(.*) )
-for line in data:
-match = re.search(pattern, line)
-if (match):
-preop_pin=match.group(1)
-break
+# Retry to read the preop.pin several times before timing out
+# due to possible race conditions
+# https://fedorahosted.org/freeipa/ticket/3382
+
+total_timeout = 0
+
+while preop_pin is None and total_timeout  api.env.startup_timeout:
+try:
+f=open(filename, 'r')
+
+data = f.read()
+data = data.split('\n')
+pattern = re.compile(preop.pin=(.*) )
+
+for line in data:
+match = re.search(pattern, line)
+if (match):
+preop_pin=match.group(1)
+break
+
+f.close()
+
+except IOError, e:
+root_logger.error(Cannot open configuration file. + str(e))
+raise e
+else:
+if preop_pin is None:
+root_logger.debug(Unable to find preop.pin.)
+root_logger.debug(Possible race condition. Waiting for 1 second.)
+total_timeout =+ 1
+time.sleep(1)
 
 if preop_pin is None:
 raise RuntimeError(Unable to find preop.pin in %s. Is your CA already configured? % filename)
-- 
1.9.3

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Petr Viktorin


On 06/11/2014 02:48 AM, Simo Sorce wrote:

I ma getting a failure to login in the UI

The error is somewhere in ldap/schema/subentry.py

KeyError: 'ipattokenhotp'

A schema update may have failed I guess ?
but running ipa-ldap-updater doesn't help ...

Ideas ?


Do you have the full traceback?


--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0053] Implement OTP token importing

2014-06-11 Thread Jan Cholasta


Hi,

On 13.5.2014 18:40, Nathaniel McCallum wrote:

On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote:

This patch adds support for importing tokens using RFC 6030 key
container files. This includes decryption support. For sysadmin sanity,
any tokens which fail to add will be written to the output file for
examination. The main use case here is where a small subset of a large
set of tokens fails to validate or add. Using the output file, the
sysadmin can attempt to recover these specific tokens.

This code is implemented as a server-side script. However, it doesn't
actually need to run on the server. This was done because importing is
an odd fit for the IPA command framework:
1. We need to write an output file.
2. The operation may be long-running (thousands of tokens).
3. Only admins need to perform this task and it only happens
infrequently.


I forgot to put the link to the ticket in the commit message. Fixed.


1) I think you should initialize NSS in ipa_otptoken_import.py, not in 
the ipa-otptoken-import script.



2) The pep8 tool reports a lot of errors in ipa_otptoken_import.py.


3) Other error messages are in the form message: %s, I think this one 
should use that form as well:


+if encoding != 'DECIMAL':
+raise ValidationError('Unsupported encoding (%s)!' % encoding)


4) This is not right:

+except:
+self.log.warn(Error adding token:  + 
str(sys.exc_info()[1]))


I think it should be something like this instead:

except ValidationError, e:
self.log.warn(Error adding token: %s, e)


5) There is no man page for ipa-otptoken-import.


6) Output file is created even when ipa-otptoken-import fails with 
Unable to connect to LDAP! Did you kinit? and other initialization 
errors, which makes subsequent ipa-otptoken-import fail with Output 
file already exists!.



7) When a key is specified by reference in Key/KeyReference instead of 
directly in Key/Data/Secret like in 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure4.xml, 
import fails with Key not found in token!. I would expect a different 
error message.



8) Importing 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure5.xml 
produces this output:


/usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: 
FutureWarning: The behavior of this method will change in future 
versions. Use specific 'len(elem)' or 'elem is not None' test instead.

  if data.get('pinpolicy', None):
Error adding token: 'NoneType' object has no attribute 'strip'


9) Using an arbitrary file in -k produces this output:

(SEC_ERROR_INVALID_KEY) The key does not support the requested operation.
Traceback (most recent call last):
  File /usr/sbin/ipa-otptoken-import, line 29, in module
nss.nss_shutdown()
nss.error.NSPRError: (SEC_ERROR_BUSY) NSS could not shutdown. Objects 
are still in use.



10) Importing 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure7.xml 
and 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure8.xml 
produces this output:


Error adding token: object of type 'NoneType' has no len()


11) Importing 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-all.xml 
or 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-all-signed.xml 
produces this output:


/usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:304: 
FutureWarning: The behavior of this method will change in future 
versions. Use specific 'len(elem)' or 'elem is not None' test instead.

  if data.get('maxtransact', None):
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: 
FutureWarning: The behavior of this method will change in future 
versions. Use specific 'len(elem)' or 'elem is not None' test instead.

  if data.get('pinpolicy', None):


12) Importing 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-invalid.xml 
succeeds, but it should fail.



13) Importing 
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/libpskc/examples/pskc-mini.xml 
fails, but it should succeed, I think.



Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote:
 On 06/11/2014 02:48 AM, Simo Sorce wrote:
  I ma getting a failure to login in the UI
 
  The error is somewhere in ldap/schema/subentry.py
 
  KeyError: 'ipattokenhotp'
 
  A schema update may have failed I guess ?
  but running ipa-ldap-updater doesn't help ...
 
  Ideas ?
 
 Do you have the full traceback?

This is in my tail output:

[Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: i18n_messages(): SUCCESS
[Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: config_show(): SUCCESS
[Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: user_find(None, whoami=True, all=True): SUCCESS
[Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: env(None): SUCCESS
[Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: dns_is_enabled(): SUCCESS
[Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: trustconfig_show(): NotFound
[Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: 
[jsonserver_session] ad...@ipa.dev.lan: batch(({u'params': ((), {}), u'method': 
u'i18n_messages'}, {u'params': ((), {}), u'method': u'config_show'}, 
{u'params': ((), {u'all': True, u'whoami': True}), u'method': u'user_find'}, 
{u'params': ((), {}), u'method': u'env'}, {u'params': ((), {}), u'method': 
u'dns_is_enabled'}, {u'params': ((), {}), u'method': u'trustconfig_show'})): 
SUCCESS
[Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: non-public: 
KeyError: 'ipatokenhotp'
[Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most recent 
call last):
[Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 343, in 
wsgi_execute
[Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = 
self.Command[name](*args, **options)
[Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__
[Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = self.run(*args, 
**options)
[Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run
[Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = 
self.execute(*args, **options)
[Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, in 
execute
[Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, 
json_serialize(o)) for o in self.api.Object()
[Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, in 
genexpr
[Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, 
json_serialize(o)) for o in self.api.Object()
[Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/util.py, line 57, in json_serialize
[Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return 
json_serialize(obj.__json__())
[Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 649, in 
__json__
[Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = 
self.api.Backend.ldap2.schema.attribute_types(objectclasses)
[Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220]   File 
/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py, line 377, in 
attribute_types
[Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = 
self.sed[ObjectClass][object_class_oid]
[Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 'ipatokenhotp'
[Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: 
[jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
object=u'all'): KeyError
[Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: 
[jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
command=u'all'): SUCCESS

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] user certificates

2014-06-11 Thread John Dennis

On 06/11/2014 04:02 AM, Fraser Tweedale wrote:
 There are other use cases for user certificates, e.g. client
 authentication for HTTP or other network services.  Perhaps you know
 of others - in which case let us know.

802.11 wireless authentication using EAP-TLS

A common discussion on the RADIUS mailing lists is the desire to deploy
using EAP-TLS but the difficulty of provisioning user certs is always
the stumbling block.

-- 
John

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile

2014-06-11 Thread Jan Cholasta


On 11.6.2014 13:29, Martin Kosek wrote:

On 06/11/2014 10:58 AM, Jan Cholasta wrote:

On 10.6.2014 09:55, Martin Kosek wrote:

On 06/06/2014 12:50 PM, Jan Cholasta wrote:

On 23.1.2014 14:34, Jan Cholasta wrote:

On 22.1.2014 16:43, Simo Sorce wrote:

On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote:

On 22.1.2014 15:34, Simo Sorce wrote:

On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote:

On 21.1.2014 17:12, Simo Sorce wrote:

Later in the patch you seem to be changing from needing
managedby_host
to needing write access to an entry, I am not sure I understand
why that
was changed. not saying it is necessarily wrong,  but why the
original
check is not right anymore ?


The original check is wrong, see
https://fedorahosted.org/freeipa/ticket/3977#comment:23.

The check in my patch allows SAN only if the requesting host has write
access to all of the SAN services. I'm not entirely sure if this is
right, but even if it is not, I think we should still check for write
access to the SAN services, so that access control can be (partially)
handled by ACIs.


Right, I remembered that comment, but it just says to check the right
object's managed-by, here instead you changed it to check if you can
write the usercertificate.

I guess it is the same *if* there is an ACI that gives write permission
when the host is in the managed-by attribute, is that the reasoning ?


Exactly. The ACIs that allow this by default are named Hosts can manage
service Certificates and kerberos keys and Hosts can manage other host
Certificates and kerberos keys.

I think the check can be extended to users as well, so that requesting
certificate with SAN is allowed only to users which have write access to
the SAN services.


I have done the modification, see attached patches.



Sounds good to me then, thanks for explaining.

The patches also look good, but I would like someone to give them a try
for a formal ack.


OK, thanks.



Bump.

I have added stricter validation of subject alt names as well as certificate
extensions in general to the second patch.


Thanks!


Updated patches attached.

Note that you will need python-nss 0.15 in order to test, you can get a RPM for
Fedora here: http://koji.fedoraproject.org/koji/buildinfo?buildID=514739.


John, do you think we could build python-nss 0.15 also for Fedora 20? The fix
incorporated in it is pretty important to warrant bugfix update in bodhi. It
would also allow FreeIPA 4.0 to be installed on Fedora 20.


Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not work,
because https://fedorahosted.org/freeipa/ticket/4370.


This worked for me, I suspect this is a DS bug. More info in the ticket.

Now back to review of the patch:

210.4: looks ok
234.4:

1) Virtual operation request certificate with subjectaltname should be a
member of Certificate Administrators privilege


OK.




2) I would write Request Certificate With SubjectAltName with with instead
of With. I.e.:
Request Certificate with SubjectAltName


OK.




3) Why is the extension check only enforced for non-hosts?

+if not bind_principal.startswith('host/'):
+for ext in extensions:
+operation = self._allowed_extensions.get(ext)
+if operation:
+self.check_access(operation)

My tricky certmonger request passed:

# ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r
-N cn=`hostname` -K host/`hostname` -D test1.example.com -D test2.example.com
-E mko...@redhat.com

while when I posted the same CSR as privileged user, it was rejected:

$ klist
Ticket cache: KEYRING:persistent:96203:96203
Default principal: f...@idm.lab.eng.brq.redhat.com

$ ipa cert-request --principal test/`hostname` certmonger.csr
ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden


Right, I meant to NACK myself, but you were faster. Fixed.




4) Regular users cannot read Virtual Operations, so even if I assign them a
permission, command is refused:

$ ipa cert-request --principal test/`hostname` openssl.csr
ipa: ERROR: Insufficient access: No such virtual command

I think we will need to create new managed permission Read Virtual Operations
and assign it to Certificate Administrators privilege by default as this
privilege has the virtual operation permissions assigned. Petr3, what is your
take on this?

Otherwise the patch worked well for me, the authorization part looked OK. My
biggest concern was just the host/user differentiation wrt unknown
subjectaltname types.

Martin



Updated patches attached.



1) I could not compile the patch set:

$ make rpms
...
if [  != yes ]; then \
./makeapi --validate; \
./makeaci --validate; \
fi
Traceback (most recent call last):
   File ./makeapi, line 457, in module
 sys.exit(main())
   File ./makeapi, line 428, in main
 api.finalize()
   File /root/freeipa-master/ipalib/plugable.py, line 708, in finalize
 self.__do_if_not_done('load_plugins')

[Freeipa-devel] [PATCH] 654 webui: fix SSH Key widget update

2014-06-11 Thread Petr Vobornik


Update widget status text on update.
--
Petr Vobornik
From f03a810d7faa7981c750a61f4cbf6af5924744e4 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 28 May 2014 16:08:23 +0200
Subject: [PATCH] webui: fix SSH Key widget update

Update widget status text on update.
---
 install/ui/src/freeipa/widget.js | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js
index 0a9c491f3ba113043303112feed64c2e8cb54b10..cfa9417c5ddbaf94b45aa35498d6076a55fac493 100644
--- a/install/ui/src/freeipa/widget.js
+++ b/install/ui/src/freeipa/widget.js
@@ -5082,7 +5082,7 @@ IPA.sshkey_widget = function(spec) {
 
 that.link = $('a/', {
 type: that.type,
-'class': 'sshkey-set link-btn',
+'class': 'sshkey-set btn btn-default',
 name: that.name,
 href: '#show-certificate',
 title: that.tooltip,
@@ -5115,6 +5115,7 @@ IPA.sshkey_widget = function(spec) {
 that.originally_set = true;
 that.original_key = that.key.key;
 }
+that.update_link();
 that.on_value_changed();
 };
 
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 655 webui: move RPC result extraction logic to Adapter

2014-06-11 Thread Petr Vobornik


It enables declarative extraction of values from partial
results of a batch commands and also further extensibility
in custom adapters.

The default adapter has detection logic for this extraction so
it can use bare record or extract data from normal or batch RPC
command.

Minor change of user plugin fixed:
https://fedorahosted.org/freeipa/ticket/4355
--
Petr Vobornik
From b90d2760c64992ef8303ad0bc674dcd695d4e8fe Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 28 May 2014 14:45:57 +0200
Subject: [PATCH] webui: move RPC result extraction logic to Adapter

It enables declarative extraction of values from partial
results of a batch commands and also further extensibility
in custom adapters.

The default adapter has detection logic for this extraction so
it can use bare record or extract data from normal or batch RPC
command.

Minor change of user plugin fixed:
https://fedorahosted.org/freeipa/ticket/4355
---
 install/ui/src/freeipa/automember.js |  2 +-
 install/ui/src/freeipa/details.js| 39 ++-
 install/ui/src/freeipa/dns.js| 19 ++---
 install/ui/src/freeipa/field.js  | 74 +---
 install/ui/src/freeipa/rule.js   |  6 +--
 install/ui/src/freeipa/service.js|  6 ++-
 install/ui/src/freeipa/user.js   | 61 +
 install/ui/src/freeipa/util.js   |  3 --
 8 files changed, 120 insertions(+), 90 deletions(-)

diff --git a/install/ui/src/freeipa/automember.js b/install/ui/src/freeipa/automember.js
index 6faddae07a034c41c9baf216c495ea35791b9aad..621ed6d1f40affc6b6fa691e0ab9e01239d42ad9 100644
--- a/install/ui/src/freeipa/automember.js
+++ b/install/ui/src/freeipa/automember.js
@@ -455,7 +455,7 @@ IPA.automember.condition_field = function(spec) {
 
 IPA.automember.condition_adapter = declare([field_mod.Adapter], {
 
-load: function(record) {
+load: function(data) {
 var regexes = this.inherited(arguments);
 var values = [];
 if (regexes) {
diff --git a/install/ui/src/freeipa/details.js b/install/ui/src/freeipa/details.js
index a3aac27c7a32eb59338d9c093f16b397b6411e56..b7fa3646921dd8a3229d1bb397373d808877fa17 100644
--- a/install/ui/src/freeipa/details.js
+++ b/install/ui/src/freeipa/details.js
@@ -237,15 +237,15 @@ exp.section_builder = IPA.section_builder = function(spec) {
  */
 that.build_section = function(section_spec, index) {
 
-var spec = section_spec;
+var spec = {};
 var overrides = {};
 var spec_type = typeof that.section_spec;
 if (spec_type === 'object') {
 spec = lang.mixin({}, that.section_spec);
-spec = lang.mixin(spec, section_spec);
 } else if (spec_type === function) {
 overrides = that.section_spec;
 }
+spec = lang.mixin(spec, section_spec);
 
 if (!spec.label  spec.name  that.container.entity) {
 var section_label = '@i18n:objects.'+that.container.entity.name+
@@ -261,7 +261,9 @@ exp.section_builder = IPA.section_builder = function(spec) {
 }, overrides);
 
 that.container.widgets.add_widget(section);
+section.$field_adapter = spec.field_adapter;
 that.create_fields(section, spec.fields);
+delete section.$field_adapter;
 };
 
 /**
@@ -283,8 +285,18 @@ exp.section_builder = IPA.section_builder = function(spec) {
  */
 that.create_field = function(section, field_spec) {
 
+if (typeof field_spec === 'string') {
+field_spec = {
+name: field_spec
+};
+}
+
 var widget = that.widget_builder.build_widget(field_spec, section.widgets);
 
+if (section.$field_adapter  !field_spec.adapter) {
+field_spec.adapter = section.$field_adapter;
+}
+
 //spec.$factory refers to widget factory
 if(field_spec.$factory) delete field_spec.$factory;
 
@@ -714,7 +726,7 @@ exp.details_facet = IPA.details_facet = function(spec, no_init) {
 var fields = that.fields.get_fields();
 for (var i=0; ifields.length; i++) {
 var field = fields[i];
-field.load(data.result.result);
+field.load(data);
 }
 that.policies.post_load(data);
 that.post_load.notify([data], that);
@@ -1467,6 +1479,10 @@ exp.boolean_state_evaluator = IPA.boolean_state_evaluator = function(spec) {
  */
 that.field_name = spec.field;
 
+that.param = spec.param || that.field_name;
+
+that.adapter = builder.build('adapter', spec.adapter || 'adapter', { context: that });
+
 /**
  * State to set when value is `true`
  * @property {string}
@@ -1504,10 +1520,10 @@ exp.boolean_state_evaluator = IPA.boolean_state_evaluator = function(spec) {
 that.on_event = function(data) {
 
 var old_state = that.state;
-var record = data.result.result;
 that.state = [];
 
-var value =

[Freeipa-devel] [PATCH] 656 webui: handle unknown result of automember-default-group-show

2014-06-11 Thread Petr Vobornik


Interface for setting default group is hidden when user doesn't have
necessary rights or if there is some error while loading the state.

https://fedorahosted.org/freeipa/ticket/4356
--
Petr Vobornik
From 317d407dbb76a0a6d54075eea435d2809314ce9b Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 28 May 2014 16:50:22 +0200
Subject: [PATCH] webui: handle unknown result of
 automember-default-group-show

Interface for setting default group is hidden when user doesn't have
necessary rights or if there is some error while loading the state.

https://fedorahosted.org/freeipa/ticket/4356
---
 install/ui/src/freeipa/automember.js | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/install/ui/src/freeipa/automember.js b/install/ui/src/freeipa/automember.js
index 621ed6d1f40affc6b6fa691e0ab9e01239d42ad9..5eff3e69bdb014a3057bf9532e420cede416e8bf 100644
--- a/install/ui/src/freeipa/automember.js
+++ b/install/ui/src/freeipa/automember.js
@@ -617,6 +617,7 @@ IPA.automember.default_group_widget = function(spec) {
 }
 
 that.update(group);
+that.set_visible(true);
 };
 
 that.update = function(group) {
@@ -646,7 +647,11 @@ IPA.automember.default_group_widget = function(spec) {
 that.refresh = function() {
 
 var command = that.create_command('show');
+command.retry = false;
 command.on_success = that.load;
+command.on_error = function() {
+that.set_visible(false);
+};
 
 command.execute();
 };
@@ -677,6 +682,7 @@ IPA.automember.default_group_widget = function(spec) {
 that.create = function(container) {
 
 var title = that.get_title();
+that.container = container;
 
 that.header = $('div/', {
 'class': 'automember-header-label',
@@ -689,6 +695,7 @@ IPA.automember.default_group_widget = function(spec) {
 that.group_select.create(that.group_select_node);
 that.group_select_node.appendTo(container);
 that.group_select.update([]); // preload groups
+that.set_visible(false);
 };
 
 that.get_title = function() {
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0064] python-kerberos update in freeipa.spec.in

2014-06-11 Thread Petr Vobornik


On 9.6.2014 16:08, Nathaniel McCallum wrote:

On Mon, 2014-06-09 at 15:59 +0200, Martin Basti wrote:

Patch attached.
View the patch for more details.


ACK



Pushed to master: d2d0da01526af41739e0eeef4273fcb71e40abc9
--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 656 webui: handle unknown result of automember-default-group-show

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 15:07 +0200, Petr Vobornik wrote:
 Interface for setting default group is hidden when user doesn't have
 necessary rights or if there is some error while loading the state.
 
 https://fedorahosted.org/freeipa/ticket/4356

ACK

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 654 webui: fix SSH Key widget update

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 15:04 +0200, Petr Vobornik wrote:
 Update widget status text on update.

ACK

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] user certificates

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 08:55 -0400, John Dennis wrote:
 On 06/11/2014 04:02 AM, Fraser Tweedale wrote:
  There are other use cases for user certificates, e.g. client
  authentication for HTTP or other network services.  Perhaps you know
  of others - in which case let us know.
 
 802.11 wireless authentication using EAP-TLS
 
 A common discussion on the RADIUS mailing lists is the desire to deploy
 using EAP-TLS but the difficulty of provisioning user certs is always
 the stumbling block.

Why EAP-TLS over EAP-TTLS? Legacy support? You can use a combo of
mechanisms to support older OSes (mainly Windows).

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 0001 - User Life Cycle (stageuser workflow)

2014-06-11 Thread thierry bordaz


Hello,

   This patch (RFE 3813)  is related to the stageuser plugin that
   handle the workflow from/to Stage users.
ipa stageuser-add login [--from-delete] [options]
ipa stageuser-mod login options
ipa stageuser-del login
ipa stageuser-find pattern
ipa stageuser-show login
ipa stageuser-activate login

   What it contains is:

 * Creation of Stage,Active, Delete containers
 * configuration of attribute uniqueness (krbPrincipalName,
   krbCanonicalName and ipaUniqueId) on Active container
 * the stageuser CLIs

   What is missing:

 * Configuration of attribute uniqueness (uid) to scope
   Active/Delete containers
 * Configuration of IPA uniqueID generator to scope Active container
 * Configuration of DNA plugin to scope Active container

thanks
thierry
From f9f7cd6e64a181c4925b30e73bd013de75d45720 Mon Sep 17 00:00:00 2001
From: Thierry bordaz (tbordaz) tbor...@redhat.com
Date: Wed, 11 Jun 2014 17:19:18 +0200
Subject: [PATCH] Ticket 3813 - User Life Cycle: introduction of stageuser
 plugin

Bug Description:
	User Life Cycle is designed http://www.freeipa.org/page/V4/User_Life-Cycle_Management
	It manages 3 containers (Staging, Active, Delete) with some workflow CLI.
	This patch supports Staging container with the following CLIs
		ipa stageuser-add login [--from-delete] [options]
		ipa stageuser-mod login options
		ipa stageuser-del login
		ipa stageuser-find pattern
		ipa stageuser-show login
		ipa stageuser-active login

Fix Description:

	stageuser-add:
		- support a --from-delete option ('givenname' and 'sn' are not required)
		  that do a MODRDN from Delete container to Staging
		- Create a Stage entry with the following particularities:
			- description: __no_upg__
			- uidNumber/gidNumber: -1
			- nsAccountLock: True
			- manager is checked to be an Active user
	stageuser-del:
	stageuser-find:
	stageuser-show:
		- nothing special
	stageuser-mod:
		- prevent modification of nsAccountLock
		- manager is checked to be an Active user
	stageuser-activate:
		- reset syntax DN attributes (except 'manager', 'secretary' and 'managedby')
		- value __no_upg__ removed from description
		- nsAccountLock: False

Reviewed by: ?

Platforms tested: F20

Flag Day: no

Doc impact: no

https://fedorahosted.org/freeipa/ticket/3813
---
 install/share/bootstrap-template.ldif |  24 +
 install/share/unique-attributes.ldif  |   6 +-
 ipalib/constants.py   |   2 +
 ipalib/plugins/stageuser.py   | 863 ++
 ipapython/ipaldap.py  |  16 +
 5 files changed, 908 insertions(+), 3 deletions(-)
 create mode 100644 ipalib/plugins/stageuser.py

diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif
index f603ad5cee26953f063ea6c28cddf1eb34a55c4a..de65979d1ce2c7c87837d8bf09a60e3c91a10e24 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -34,6 +34,30 @@ objectClass: top
 objectClass: nsContainer
 cn: hostgroups
 
+dn: cn=provisioning,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: nsContainer
+cn: provisioning
+
+dn: cn=accounts,cn=provisioning,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: nsContainer
+cn: accounts
+
+dn: cn=staged users,cn=accounts,cn=provisioning,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: nsContainer
+cn: staged users
+
+dn: cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: nsContainer
+cn: deleted users
+
 dn: cn=alt,$SUFFIX
 changetype: add
 objectClass: nsContainer
diff --git a/install/share/unique-attributes.ldif b/install/share/unique-attributes.ldif
index 0e680a0e45b455469f9be9555aed1e63f1d97faf..3af71ef5e2f78860fb5388247a9fdbc2055173e8 100644
--- a/install/share/unique-attributes.ldif
+++ b/install/share/unique-attributes.ldif
@@ -9,7 +9,7 @@ nsslapd-pluginInitfunc: NSUniqueAttr_Init
 nsslapd-pluginType: preoperation
 nsslapd-pluginEnabled: on
 nsslapd-pluginarg0: krbPrincipalName
-nsslapd-pluginarg1: $SUFFIX
+nsslapd-pluginarg1: cn=accounts,$SUFFIX
 nsslapd-plugin-depends-on-type: database
 nsslapd-pluginId: NSUniqueAttr
 nsslapd-pluginVersion: 1.1.0
@@ -27,7 +27,7 @@ nsslapd-pluginInitfunc: NSUniqueAttr_Init
 nsslapd-pluginType: preoperation
 nsslapd-pluginEnabled: on
 nsslapd-pluginarg0: krbCanonicalName
-nsslapd-pluginarg1: $SUFFIX
+nsslapd-pluginarg1: cn=accounts,$SUFFIX
 nsslapd-plugin-depends-on-type: database
 nsslapd-pluginId: NSUniqueAttr
 nsslapd-pluginVersion: 1.1.0
@@ -63,7 +63,7 @@ nsslapd-pluginInitfunc: NSUniqueAttr_Init
 nsslapd-pluginType: preoperation
 nsslapd-pluginEnabled: on
 nsslapd-pluginarg0: ipaUniqueID
-nsslapd-pluginarg1: $SUFFIX
+nsslapd-pluginarg1: cn=accounts,$SUFFIX
 nsslapd-plugin-depends-on-type: database
 nsslapd-pluginId: NSUniqueAttr
 nsslapd-pluginVersion: 1.1.0
diff --git a/ipalib/constants.py b/ipalib/constants.py
index

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
 On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote:
  On 06/11/2014 02:48 AM, Simo Sorce wrote:
   I ma getting a failure to login in the UI
  
   The error is somewhere in ldap/schema/subentry.py
  
   KeyError: 'ipattokenhotp'
  
   A schema update may have failed I guess ?
   but running ipa-ldap-updater doesn't help ...
  
   Ideas ?
  
  Do you have the full traceback?
 
 This is in my tail output:
 
 [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: 
 ad...@ipa.dev.lan: batch: i18n_messages(): SUCCESS
 [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: 
 ad...@ipa.dev.lan: batch: config_show(): SUCCESS
 [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: 
 ad...@ipa.dev.lan: batch: user_find(None, whoami=True, all=True): SUCCESS
 [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: 
 ad...@ipa.dev.lan: batch: env(None): SUCCESS
 [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: 
 ad...@ipa.dev.lan: batch: dns_is_enabled(): SUCCESS
 [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: 
 ad...@ipa.dev.lan: batch: trustconfig_show(): NotFound
 [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: 
 [jsonserver_session] ad...@ipa.dev.lan: batch(({u'params': ((), {}), 
 u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': 
 u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), 
 u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, 
 {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), {}), 
 u'method': u'trustconfig_show'})): SUCCESS
 [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: non-public: 
 KeyError: 'ipatokenhotp'
 [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most recent 
 call last):
 [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220]   File 
 /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 343, in 
 wsgi_execute
 [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = 
 self.Command[name](*args, **options)
 [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220]   File 
 /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__
 [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = 
 self.run(*args, **options)
 [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220]   File 
 /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run
 [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = 
 self.execute(*args, **options)
 [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220]   File 
 /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, in 
 execute
 [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, 
 json_serialize(o)) for o in self.api.Object()
 [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220]   File 
 /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, in 
 genexpr
 [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, 
 json_serialize(o)) for o in self.api.Object()
 [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220]   File 
 /usr/lib/python2.7/site-packages/ipalib/util.py, line 57, in json_serialize
 [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return 
 json_serialize(obj.__json__())
 [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220]   File 
 /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 649, in 
 __json__
 [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = 
 self.api.Backend.ldap2.schema.attribute_types(objectclasses)
 [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220]   File 
 /usr/lib64/python2.7/site-packages/ldap/schema/subentry.py, line 377, in 
 attribute_types
 [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = 
 self.sed[ObjectClass][object_class_oid]
 [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 'ipatokenhotp'
 [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: 
 [jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
 object=u'all'): KeyError
 [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: 
 [jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
 command=u'all'): SUCCESS

Do the installed schema files have ipatokenHOTP? Did you dump the schema
from 389DS to see if this object class is present?

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0018] Fix --ttl description for DNS zones

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 13:26 +0200, Petr Spacek wrote:
 Hello,
 
 Fix --ttl description for DNS zones
 
 TTL specified in idnsZone object class affects all records at zone apex,
 not only SOA record.
 
 I have realized that current description is incorrect when I was doing doc 
 review.

ACK

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed

2014-06-11 Thread Petr Viktorin


Patch 0578 does the conversion

Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and 
provides permissions needed for automatic enrollment (from 
http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser)



--
Petr³
From 7b138f8170cfce71f6cec55ad21cb27a2ef581b1 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Fri, 30 May 2014 18:35:31 +0200
Subject: [PATCH] Convert Host default permissions to managed

Part of the work for: https://fedorahosted.org/freeipa/ticket/4346
---
 ACI.txt  | 14 ++
 install/share/delegation.ldif| 82 
 install/updates/40-delegation.update | 29 +
 ipalib/plugins/host.py   | 62 +++
 4 files changed, 77 insertions(+), 110 deletions(-)

diff --git a/ACI.txt b/ACI.txt
index 2ceaacc077467b6ef54e09d0aa7d3d5695c8fd40..f4132c3713560afdbd543497a0827fa852b5d7e2 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -20,10 +20,24 @@ dn: cn=System: Read HBAC Services,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = cn || description || ipauniqueid || memberof || objectclass)(targetfilter = (objectclass=ipahbacservice))(version 3.0;acl permission:System: Read HBAC Services;allow (compare,read,search) userdn = ldap:///all;;)
 dn: cn=System: Read HBAC Service Groups,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = businesscategory || cn || description || ipauniqueid || member || memberhost || memberuser || o || objectclass || ou || owner || seealso)(targetfilter = (objectclass=ipahbacservicegroup))(version 3.0;acl permission:System: Read HBAC Service Groups;allow (compare,read,search) userdn = ldap:///all;;)
+dn: cn=System: Add Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Add Hosts;allow (add) groupdn = ldap:///cn=System: Add Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example;)
+dn: cn=System: Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = krbprincipalname)(targetfilter = ((!(krbprincipalname=*))(objectclass=ipahost)))(version 3.0;acl permission:System: Add krbPrincipalName to a host;allow (write) groupdn = ldap:///cn=System: Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=ipa,dc=example;)
+dn: cn=System: Enroll a host,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = objectclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Enroll a host;allow (write) groupdn = ldap:///cn=System: Enroll a host,cn=permissions,cn=pbac,dc=ipa,dc=example;)
+dn: cn=System: Manage Host SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = ipasshpubkey)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Manage Host SSH Public Keys;allow (write) groupdn = ldap:///cn=System: Manage Host SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example;)
+dn: cn=System: Manage host keytab,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = krblastpwdchange || krbprincipalkey)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Manage host keytab;allow (write) groupdn = ldap:///cn=System: Manage host keytab,cn=permissions,cn=pbac,dc=ipa,dc=example;)
+dn: cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetattr = description || l || nshardwareplatform || nshostlocation || nsosversion)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Modify Hosts;allow (write) groupdn = ldap:///cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example;)
 dn: cn=System: Read Host Membership,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = memberof)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Read Host Membership;allow (compare,read,search) userdn = ldap:///all;;)
 dn: cn=System: Read Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = cn || description || enrolledby || fqdn || ipaclientversion || ipakrbauthzdata || ipasshpubkey || ipauniqueid || krbcanonicalname || krblastpwdchange || krbpasswordexpiration || krbprincipalaliases || krbprincipalexpiration || krbprincipalname || l || macaddress || managedby || nshardwareplatform || nshostlocation || nsosversion || objectclass || serverhostname || usercertificate || userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Read Hosts;allow (compare,read,search) userdn = ldap:///all;;)
+dn: cn=System: Remove Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example
+aci: (targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Remove Hosts;allow (delete) groupdn = ldap:///cn=System: Remove Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example;)
 dn: cn=System: Read Hostgroup Membership,cn=permissions,cn=pbac,dc=ipa,dc=example
 aci: (targetattr = member || memberhost || memberof || memberuser)(targetfilter = (objectclass=ipahostgroup))(version 3.0;acl

Re: [Freeipa-devel] [PATCH 0049] Add support for protected tokens

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote:
 On 05/13/2014 04:33 PM, Jan Cholasta wrote:
  On 12.5.2014 21:02, Nathaniel McCallum wrote:
  On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
  On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
  On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote:
  On 05/07/2014 09:05 AM, Nathaniel McCallum wrote:
  On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote:
  Hi,
 
  On 6.5.2014 17:08, Nathaniel McCallum wrote:
  On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote:
  On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote:
  This also constitutes a rethinking of the token ACIs after the
  introduction of SELFDN support.
 
  Admins, as before, have full access to all token permissions.
 
  Normal users have read/search/compare access to all of the 
  non-secret
  data for tokens assigned to them, whether protected or 
  non-protected.
  Users can add or delete non-protected tokens and modify most 
  of their
  metadata. However they cannot create, delete or modify 
  protected tokens.
  Regardless of whether the token is protected or not, users 
  cannot change
  a token's ownership or unique identity.
 
  In contrast, admins can create protected tokens. This 
  protects the token
  from deletion or modification when assigned to users. 
  Additionally, when
  a user account is deleted, the assigned non-protected tokens 
  are deleted
  but the protected tokens are merely orphaned. This permits 
  the token to
  be reassigned without having to recreate it. This last point is
  particularly useful in the case of hardware tokens.
 
  https://fedorahosted.org/freeipa/ticket/4228
 
  NOTE: This patch depends on my patch 0048.
  This new version makes ipatokenDisabled visible for token 
  owners. It is
  also writable if the token is non-protected. This 
  additionally fixes:
 
  https://fedorahosted.org/freeipa/ticket/4259
  This new version changes the way the default value of 
  protected is setup
  in accordance with the changes made for the review of my patch 
  0048.2.
 
  Nathaniel
  Is using the ipatokenprotected attribute the final design?
  No. Alternate designs are welcome. The code is easy enough to 
  modify.
 
  I did not dig too deep into this, but I think it might be 
  better to
  instead use the managedby attribute on a token to limit who can 
  delete
  (or administer in other way) the token. On otptoken-add, 
  managedby would
  be set to the whoami user DN, unless run with --protected, in 
  which
  case managedby would be left empty. Then, when deleting a user, 
  the
  token would be deleted only if the user manages the token.
  It seems to me that the mechanics of this are roughly the same as
  protected, just with a different syntax. The cost of this is more
  complex ACIs. In particular, we'd have to use two userdn clauses 
  (is
  this possible?) instead of a simple filter. If there is a clear 
  benefit,
  we can justify the more obtuse syntax.
 
  We usually try not to create new attributes until it is fully 
  justified.
  I would like Simo to chime in on this.
 
  I would also prefer to reuse existing attributes and mechanism if
  possible and if it will not preclude future work.
 
  In this case, it sounds like managed-by has the appropriate 
  meaning:
  who manages the token ? - myself, admin, other, none ?
 
  Nathaniel can you send 2 lines showing the difference in ACIs between
  using managed-by vs a new attribute ?
 
  These are the ACIs using the protected mechanism:
 
  aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
  objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
  ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
  ipatokenModel
  || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
  acl Users can read basic token info; allow (read, search, compare)
  userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits ||
  ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
  allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl 
  Users can
  see HOTP details; allow (read, search, compare) userattr =
  ipatokenOwner#USERDN;)
 
  aci: (targetfilter =
  ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
  description || ipatokenDisabled || ipatokenNotBefore ||
  ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
  ipatokenSerial)(version 3.0; acl Users can write basic token info;
  allow (write) userattr = ipatokenOwner#USERDN;)
 
  aci: (target = 
  ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
  = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 
  3.0;
  acl Users can create and delete tokens; allow

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:
 On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
  On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote:
   On 06/11/2014 02:48 AM, Simo Sorce wrote:
I ma getting a failure to login in the UI
   
The error is somewhere in ldap/schema/subentry.py
   
KeyError: 'ipattokenhotp'
   
A schema update may have failed I guess ?
but running ipa-ldap-updater doesn't help ...
   
Ideas ?
   
   Do you have the full traceback?
  
  This is in my tail output:
  
  [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: 
  ad...@ipa.dev.lan: batch: i18n_messages(): SUCCESS
  [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: 
  ad...@ipa.dev.lan: batch: config_show(): SUCCESS
  [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: 
  ad...@ipa.dev.lan: batch: user_find(None, whoami=True, all=True): SUCCESS
  [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: 
  ad...@ipa.dev.lan: batch: env(None): SUCCESS
  [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: 
  ad...@ipa.dev.lan: batch: dns_is_enabled(): SUCCESS
  [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: 
  ad...@ipa.dev.lan: batch: trustconfig_show(): NotFound
  [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: 
  [jsonserver_session] ad...@ipa.dev.lan: batch(({u'params': ((), {}), 
  u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': 
  u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), 
  u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, 
  {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), {}), 
  u'method': u'trustconfig_show'})): SUCCESS
  [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: 
  non-public: KeyError: 'ipatokenhotp'
  [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most 
  recent call last):
  [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220]   File 
  /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 343, in 
  wsgi_execute
  [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = 
  self.Command[name](*args, **options)
  [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220]   File 
  /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__
  [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = 
  self.run(*args, **options)
  [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220]   File 
  /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run
  [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = 
  self.execute(*args, **options)
  [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220]   File 
  /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, in 
  execute
  [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, 
  json_serialize(o)) for o in self.api.Object()
  [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220]   File 
  /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, in 
  genexpr
  [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, 
  json_serialize(o)) for o in self.api.Object()
  [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220]   File 
  /usr/lib/python2.7/site-packages/ipalib/util.py, line 57, in 
  json_serialize
  [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return 
  json_serialize(obj.__json__())
  [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220]   File 
  /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 649, in 
  __json__
  [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = 
  self.api.Backend.ldap2.schema.attribute_types(objectclasses)
  [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220]   File 
  /usr/lib64/python2.7/site-packages/ldap/schema/subentry.py, line 377, in 
  attribute_types
  [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = 
  self.sed[ObjectClass][object_class_oid]
  [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 
  'ipatokenhotp'
  [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: 
  [jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
  object=u'all'): KeyError
  [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: 
  [jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
  command=u'all'): SUCCESS
 
 Do the installed schema files have ipatokenHOTP? Did you dump the schema
 from 389DS to see if this object class is present?

They are not. The schema files in /usr/share/ipa do have the
objectclasses, but the server schema has not been updated (or the update
failed).

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 12:45 -0400, Simo Sorce wrote:
 On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
   On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote:
On 06/11/2014 02:48 AM, Simo Sorce wrote:
 I ma getting a failure to login in the UI

 The error is somewhere in ldap/schema/subentry.py

 KeyError: 'ipattokenhotp'

 A schema update may have failed I guess ?
 but running ipa-ldap-updater doesn't help ...

 Ideas ?

Do you have the full traceback?
   
   This is in my tail output:
   
   [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: 
   ad...@ipa.dev.lan: batch: i18n_messages(): SUCCESS
   [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: 
   ad...@ipa.dev.lan: batch: config_show(): SUCCESS
   [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: 
   ad...@ipa.dev.lan: batch: user_find(None, whoami=True, all=True): SUCCESS
   [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: 
   ad...@ipa.dev.lan: batch: env(None): SUCCESS
   [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: 
   ad...@ipa.dev.lan: batch: dns_is_enabled(): SUCCESS
   [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: 
   ad...@ipa.dev.lan: batch: trustconfig_show(): NotFound
   [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: 
   [jsonserver_session] ad...@ipa.dev.lan: batch(({u'params': ((), {}), 
   u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': 
   u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), 
   u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, 
   {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), 
   {}), u'method': u'trustconfig_show'})): SUCCESS
   [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: 
   non-public: KeyError: 'ipatokenhotp'
   [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most 
   recent call last):
   [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220]   File 
   /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 343, in 
   wsgi_execute
   [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = 
   self.Command[name](*args, **options)
   [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220]   File 
   /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in 
   __call__
   [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = 
   self.run(*args, **options)
   [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220]   File 
   /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run
   [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = 
   self.execute(*args, **options)
   [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220]   File 
   /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, 
   in execute
   [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, 
   json_serialize(o)) for o in self.api.Object()
   [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220]   File 
   /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 119, 
   in genexpr
   [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, 
   json_serialize(o)) for o in self.api.Object()
   [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220]   File 
   /usr/lib/python2.7/site-packages/ipalib/util.py, line 57, in 
   json_serialize
   [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return 
   json_serialize(obj.__json__())
   [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220]   File 
   /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 649, 
   in __json__
   [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = 
   self.api.Backend.ldap2.schema.attribute_types(objectclasses)
   [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220]   File 
   /usr/lib64/python2.7/site-packages/ldap/schema/subentry.py, line 377, 
   in attribute_types
   [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = 
   self.sed[ObjectClass][object_class_oid]
   [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 
   'ipatokenhotp'
   [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: 
   [jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
   object=u'all'): KeyError
   [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: 
   [jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
   command=u'all'): SUCCESS
  
  Do the installed schema files have ipatokenHOTP? Did you dump the schema
  from 389DS to see if this object class is present?
 
 They are not. The schema files in /usr/share/ipa do have the
 objectclasses, but the server schema has not been updated (or the update
 failed).

Hrm. Does it have ipatokenTOTP?

___
Freeipa-devel mailing list

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Petr Viktorin


On 06/11/2014 06:45 PM, Simo Sorce wrote:

On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:

On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:




Do the installed schema files have ipatokenHOTP? Did you dump the schema
from 389DS to see if this object class is present?


They are not. The schema files in /usr/share/ipa do have the
objectclasses, but the server schema has not been updated (or the update
failed).


Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or 
send it and I can check.



--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote:
 Hi,
 
 As due to possible race conditions, the preop.pin might not be
 written in the CS.cfg at the time installer tries to read it.
 
 In case no value for preop.pin was found, retry until timeout
 was reached.
 
 https://fedorahosted.org/freeipa/ticket/3382
 
 (applies on ipa-3-0 branch)

There is inconsistent spacing around '='. For instance:
+f=open(filename, 'r')
+data = f.read()

Also, I'm fairly certain this is incorrect:
+total_timeout =+ 1

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 12:47 -0400, Nathaniel McCallum wrote:
 On Wed, 2014-06-11 at 12:45 -0400, Simo Sorce wrote:
  On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:
   On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote:
 On 06/11/2014 02:48 AM, Simo Sorce wrote:
  I ma getting a failure to login in the UI
 
  The error is somewhere in ldap/schema/subentry.py
 
  KeyError: 'ipattokenhotp'
 
  A schema update may have failed I guess ?
  but running ipa-ldap-updater doesn't help ...
 
  Ideas ?
 
 Do you have the full traceback?

This is in my tail output:

[Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: i18n_messages(): SUCCESS
[Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: config_show(): SUCCESS
[Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: user_find(None, whoami=True, all=True): 
SUCCESS
[Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: env(None): SUCCESS
[Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: dns_is_enabled(): SUCCESS
[Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: 
ad...@ipa.dev.lan: batch: trustconfig_show(): NotFound
[Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: 
[jsonserver_session] ad...@ipa.dev.lan: batch(({u'params': ((), {}), 
u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': 
u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), 
u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, 
{u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), 
{}), u'method': u'trustconfig_show'})): SUCCESS
[Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: 
non-public: KeyError: 'ipatokenhotp'
[Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most 
recent call last):
[Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 343, in 
wsgi_execute
[Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = 
self.Command[name](*args, **options)
[Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in 
__call__
[Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = 
self.run(*args, **options)
[Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run
[Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = 
self.execute(*args, **options)
[Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 
119, in execute
[Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, 
json_serialize(o)) for o in self.api.Object()
[Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 
119, in genexpr
[Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, 
json_serialize(o)) for o in self.api.Object()
[Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/util.py, line 57, in 
json_serialize
[Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return 
json_serialize(obj.__json__())
[Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220]   File 
/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 
649, in __json__
[Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = 
self.api.Backend.ldap2.schema.attribute_types(objectclasses)
[Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220]   File 
/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py, line 377, 
in attribute_types
[Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class 
= self.sed[ObjectClass][object_class_oid]
[Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 
'ipatokenhotp'
[Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: 
[jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
object=u'all'): KeyError
[Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: 
[jsonserver_session] ad...@ipa.dev.lan: json_metadata(None, None, 
command=u'all'): SUCCESS
   
   Do the installed schema files have ipatokenHOTP? Did you dump the schema
   from 389DS to see if this object class is present?
  
  They are not. The schema files in /usr/share/ipa do have the
  objectclasses, but the server schema

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote:
 On 06/11/2014 06:45 PM, Simo Sorce wrote:
  On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
 
 
  Do the installed schema files have ipatokenHOTP? Did you dump the schema
  from 389DS to see if this object class is present?
 
  They are not. The schema files in /usr/share/ipa do have the
  objectclasses, but the server schema has not been updated (or the update
  failed).
 
 Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or 
 send it and I can check.

Uhmm it failed because I previously had one of the getkeytab attributes
in the server but we later changed its OID when the feature was
deferred... sigh ...

I now have removed the offending attributes by turning off dirsrv and
manually removing them from 99user.ldif, but running ipa-ldap-updater
does not seem to do try to add the missing schema ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] user certificates

2014-06-11 Thread John Dennis

On 06/11/2014 12:12 PM, Nathaniel McCallum wrote:
 On Wed, 2014-06-11 at 08:55 -0400, John Dennis wrote:
 On 06/11/2014 04:02 AM, Fraser Tweedale wrote:
 There are other use cases for user certificates, e.g. client
 authentication for HTTP or other network services.  Perhaps you know
 of others - in which case let us know.

 802.11 wireless authentication using EAP-TLS

 A common discussion on the RADIUS mailing lists is the desire to deploy
 using EAP-TLS but the difficulty of provisioning user certs is always
 the stumbling block.
 
 Why EAP-TLS over EAP-TTLS? Legacy support? You can use a combo of
 mechanisms to support older OSes (mainly Windows).

Because EAP-TLS is what is used for mutual client/server authentication
using PKI. EAP-TLS is supported on more legacy OS's (e.g. older
Windows). Microsoft only started supporting EAP-TTLS in Windows 8.
EAP-TLS is considered very secure and my (unconfirmed) understanding is
it's somewhat common with enterprise Windows deployments because
Microsoft makes it easy to provision client certs.

EAP-TTLS is primarily to set up a tunnel for other (less secure) methods
so that sensitive information is not in the clear. Note the leading T in
TTLS refers to tunnel. Client authentication is optional with
EAP-TTLS. You could establish a TLS tunnel with EAP-TTLS and then run
EAP-TLS inside the tunnel but the two TLS sessions make it much less
efficient, the advantage is the username can be anonymous with
EAP-TTLS/EAP-TLS if that's actually a concern. If you're not concerned
about user anonymity (outer identity) then there is no value in
establishing a tunnel to run other authentication protocols in, with
EAP-TLS simply being able to complete the SSL handshake (with the
required client cert) is sufficient to establish authentication.

-- 
John

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Petr Viktorin


On 06/11/2014 06:58 PM, Simo Sorce wrote:

On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote:

On 06/11/2014 06:45 PM, Simo Sorce wrote:

On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:

On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:




Do the installed schema files have ipatokenHOTP? Did you dump the schema
from 389DS to see if this object class is present?


They are not. The schema files in /usr/share/ipa do have the
objectclasses, but the server schema has not been updated (or the update
failed).


Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or
send it and I can check.


Uhmm it failed because I previously had one of the getkeytab attributes
in the server but we later changed its OID when the feature was
deferred... sigh ...


Yeah, that would be a problem.


I now have removed the offending attributes by turning off dirsrv and
manually removing them from 99user.ldif, but running ipa-ldap-updater
does not seem to do try to add the missing schema ...


Are you saying there's nothing about schema in the log?

--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] user certificates

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 13:07 -0400, John Dennis wrote:
 On 06/11/2014 12:12 PM, Nathaniel McCallum wrote:
  On Wed, 2014-06-11 at 08:55 -0400, John Dennis wrote:
  On 06/11/2014 04:02 AM, Fraser Tweedale wrote:
  There are other use cases for user certificates, e.g. client
  authentication for HTTP or other network services.  Perhaps you know
  of others - in which case let us know.
 
  802.11 wireless authentication using EAP-TLS
 
  A common discussion on the RADIUS mailing lists is the desire to deploy
  using EAP-TLS but the difficulty of provisioning user certs is always
  the stumbling block.
  
  Why EAP-TLS over EAP-TTLS? Legacy support? You can use a combo of
  mechanisms to support older OSes (mainly Windows).
 
 Because EAP-TLS is what is used for mutual client/server authentication
 using PKI. EAP-TLS is supported on more legacy OS's (e.g. older
 Windows). Microsoft only started supporting EAP-TTLS in Windows 8.
 EAP-TLS is considered very secure and my (unconfirmed) understanding is

*cough*heartbleed*cough* ;)

 it's somewhat common with enterprise Windows deployments because
 Microsoft makes it easy to provision client certs.
 
 EAP-TTLS is primarily to set up a tunnel for other (less secure) methods
 so that sensitive information is not in the clear. Note the leading T in
 TTLS refers to tunnel. Client authentication is optional with
 EAP-TTLS. You could establish a TLS tunnel with EAP-TTLS and then run
 EAP-TLS inside the tunnel but the two TLS sessions make it much less
 efficient, the advantage is the username can be anonymous with
 EAP-TTLS/EAP-TLS if that's actually a concern. If you're not concerned
 about user anonymity (outer identity) then there is no value in
 establishing a tunnel to run other authentication protocols in, with
 EAP-TLS simply being able to complete the SSL handshake (with the
 required client cert) is sufficient to establish authentication.

Yes, this I understand. But in my experience, TTLS is being widely
deployed in combination with an inner client authentication precisely
because TLS was so hard to maintain. MS fought TTLS for a long time and
eventually gave in in Windows 8 precisely because so many people were
deploying TTLS with an inner authenticator.

I can't think of a single example of a TLS deployment that can't be
given a better user experience by migrating to TTLS (old Windows
excluded of course).

Nathaniel



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 19:08 +0200, Petr Viktorin wrote:
 On 06/11/2014 06:58 PM, Simo Sorce wrote:
  On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote:
  On 06/11/2014 06:45 PM, Simo Sorce wrote:
  On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
 
 
  Do the installed schema files have ipatokenHOTP? Did you dump the schema
  from 389DS to see if this object class is present?
 
  They are not. The schema files in /usr/share/ipa do have the
  objectclasses, but the server schema has not been updated (or the update
  failed).
 
  Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or
  send it and I can check.
 
  Uhmm it failed because I previously had one of the getkeytab attributes
  in the server but we later changed its OID when the feature was
  deferred... sigh ...
 
 Yeah, that would be a problem.
 
  I now have removed the offending attributes by turning off dirsrv and
  manually removing them from 99user.ldif, but running ipa-ldap-updater
  does not seem to do try to add the missing schema ...
 
 Are you saying there's nothing about schema in the log?

Not for following ipa-ldap-update runs ... they seem to actually fail
with a timeout ... investigating.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 13:32 -0400, Simo Sorce wrote:
 On Wed, 2014-06-11 at 13:30 -0400, Simo Sorce wrote:
  On Wed, 2014-06-11 at 19:08 +0200, Petr Viktorin wrote:
   On 06/11/2014 06:58 PM, Simo Sorce wrote:
On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote:
On 06/11/2014 06:45 PM, Simo Sorce wrote:
On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:
On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
   
   
Do the installed schema files have ipatokenHOTP? Did you dump the 
schema
from 389DS to see if this object class is present?
   
They are not. The schema files in /usr/share/ipa do have the
objectclasses, but the server schema has not been updated (or the 
update
failed).
   
Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or
send it and I can check.
   
Uhmm it failed because I previously had one of the getkeytab attributes
in the server but we later changed its OID when the feature was
deferred... sigh ...
   
   Yeah, that would be a problem.
   
I now have removed the offending attributes by turning off dirsrv and
manually removing them from 99user.ldif, but running ipa-ldap-updater
does not seem to do try to add the missing schema ...
   
   Are you saying there's nothing about schema in the log?
  
  Not for following ipa-ldap-update runs ... they seem to actually fail
  with a timeout ... investigating.
 
 Nevermind, I re-run ipa-ldap-updater and this time it is trying (but it
 found another of the old attributes I hadn't deleted. I don't know why
 previous attempts at running ipa-ldap-updater failed, but I did reboot
 the machine since ... so maybe there was something wonky about DS.

Ok now ipa-ldap-updater does a lot more and passes through schema
upgrade, however it fails again later complaining ipaVirtualOperation is
an unknown object class ..

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 13:30 -0400, Simo Sorce wrote:
 On Wed, 2014-06-11 at 19:08 +0200, Petr Viktorin wrote:
  On 06/11/2014 06:58 PM, Simo Sorce wrote:
   On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote:
   On 06/11/2014 06:45 PM, Simo Sorce wrote:
   On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote:
   On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote:
  
  
   Do the installed schema files have ipatokenHOTP? Did you dump the 
   schema
   from 389DS to see if this object class is present?
  
   They are not. The schema files in /usr/share/ipa do have the
   objectclasses, but the server schema has not been updated (or the update
   failed).
  
   Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or
   send it and I can check.
  
   Uhmm it failed because I previously had one of the getkeytab attributes
   in the server but we later changed its OID when the feature was
   deferred... sigh ...
  
  Yeah, that would be a problem.
  
   I now have removed the offending attributes by turning off dirsrv and
   manually removing them from 99user.ldif, but running ipa-ldap-updater
   does not seem to do try to add the missing schema ...
  
  Are you saying there's nothing about schema in the log?
 
 Not for following ipa-ldap-update runs ... they seem to actually fail
 with a timeout ... investigating.

Nevermind, I re-run ipa-ldap-updater and this time it is trying (but it
found another of the old attributes I hadn't deleted. I don't know why
previous attempts at running ipa-ldap-updater failed, but I did reboot
the machine since ... so maybe there was something wonky about DS.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote:
 Ok now ipa-ldap-updater does a lot more and passes through schema
 upgrade, however it fails again later complaining ipaVirtualOperation
 is
 an unknown object class ..

Ok I manually added ipaVirtualOperation to user99.ldif, and the updater
made some more progress, but now complains it doesn't know about
ipapermissionv2 ...

Why is the updater failing to recognize that some schema is missing ?
I see it checking the schema file but it tries to replace a few
attributes (every time) where the only thing that differs is the
X-ORIGIN and does nothing else ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote:
 On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote:
  Ok now ipa-ldap-updater does a lot more and passes through schema
  upgrade, however it fails again later complaining ipaVirtualOperation
  is
  an unknown object class ..
 
 Ok I manually added ipaVirtualOperation to user99.ldif, and the updater
 made some more progress, but now complains it doesn't know about
 ipapermissionv2 ...
 
 Why is the updater failing to recognize that some schema is missing ?
 I see it checking the schema file but it tries to replace a few
 attributes (every time) where the only thing that differs is the
 X-ORIGIN and does nothing else ...

Ok after adding a few manually also some schema for dna plugin was
missing, I decided to use the big hammer and simply copied all schema
files from /etc/dirsrv/schema and /usr/share/ipa in the ds schema
directory.

This way ipa-ldap-updater finished successfully.

And after a restart of httpd the UI came up.
So *hopefully* all is ok now ...

Should I open a ticket about ipa-ldap-updater being unsuccessful at
updating ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Petr Viktorin


On 06/11/2014 08:17 PM, Simo Sorce wrote:

On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote:

On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote:

Ok now ipa-ldap-updater does a lot more and passes through schema
upgrade, however it fails again later complaining ipaVirtualOperation
is
an unknown object class ..


Ok I manually added ipaVirtualOperation to user99.ldif, and the updater
made some more progress, but now complains it doesn't know about
ipapermissionv2 ...


Simo, could you please post the actual error message when something goes 
wrong? Otherwise I can't really debug this.




Why is the updater failing to recognize that some schema is missing ?
I see it checking the schema file but it tries to replace a few
attributes (every time) where the only thing that differs is the
X-ORIGIN and does nothing else ...


Ok after adding a few manually also some schema for dna plugin was
missing, I decided to use the big hammer and simply copied all schema
files from /etc/dirsrv/schema and /usr/share/ipa in the ds schema
directory.

This way ipa-ldap-updater finished successfully.

And after a restart of httpd the UI came up.
So *hopefully* all is ok now ...

Should I open a ticket about ipa-ldap-updater being unsuccessful at
updating ?


Sure. Just include the debugging info; your system seems to be quite 
special.



--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Woes updating and oldish devel server to latest master

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 20:50 +0200, Petr Viktorin wrote:
 On 06/11/2014 08:17 PM, Simo Sorce wrote:
  On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote:
  On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote:
  Ok now ipa-ldap-updater does a lot more and passes through schema
  upgrade, however it fails again later complaining ipaVirtualOperation
  is
  an unknown object class ..
 
  Ok I manually added ipaVirtualOperation to user99.ldif, and the updater
  made some more progress, but now complains it doesn't know about
  ipapermissionv2 ...
 
 Simo, could you please post the actual error message when something goes 
 wrong? Otherwise I can't really debug this.

More or less the same as before, it is understandable that operations
fail when the schema they depend on is not available. The problem is
that the schema hasn't been updated, not where it fails because it is
missing.

  Why is the updater failing to recognize that some schema is missing ?
  I see it checking the schema file but it tries to replace a few
  attributes (every time) where the only thing that differs is the
  X-ORIGIN and does nothing else ...
 
  Ok after adding a few manually also some schema for dna plugin was
  missing, I decided to use the big hammer and simply copied all schema
  files from /etc/dirsrv/schema and /usr/share/ipa in the ds schema
  directory.
 
  This way ipa-ldap-updater finished successfully.
 
  And after a restart of httpd the UI came up.
  So *hopefully* all is ok now ...
 
  Should I open a ticket about ipa-ldap-updater being unsuccessful at
  updating ?
 
 Sure. Just include the debugging info; your system seems to be quite 
 special.

I would say battle-tested :-)

But honestly I do not think this is a common problem, it was just me
messing up with the schema previously and forgetting I'd done that.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs

2014-06-11 Thread Simo Sorce

On Tue, 2014-06-10 at 20:13 -0400, Simo Sorce wrote:
 Still upgrading my server, so still untested, but again just to catch
 style issues, I'll post news once I can test the changes do not break
 functionality.

I finished upgrading the server and redone my functional testing.
Both getting ad setting keys seem to work as expected with the last
batch of patches.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs

2014-06-11 Thread Rob Crittenden

Simo Sorce wrote:
 On Tue, 2014-06-10 at 14:27 -0400, Nathaniel McCallum wrote:
 On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote:
 On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote:
 On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote:
 On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote:
 On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote:
 On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote:
 Simo Sorce wrote:
 This patch set is an initial implementation of ticket #3859

 It seem to be working fine in my initial testing but I have not yet
 tested all cases.

 However I wonted to throw it on the list to get some initial feedback
 about the choices I made wrt access control and ipa-getkeytab flags 
 and
 default behavior.

 In particular, the current patch set would require us to make
 host/service keytabs readable by the requesting party (whoever that 
 is,
 admin or host itself) in order to allow it to get back the actual
 keytab. I am not sure this is ideal. Also write access to the keytab 
 is
 still all is needed to allow someone to change it.

 Neither is ideal, but it was simpler as a first implementation. In
 particular I think we should allow either permission indipendently, 
 and
 it should be something an admin can change. However I do not like
 allowing normal writes or reads to these attributes, mostly because 
 w/o
 access to the master key nobody can really make sense of actually
 reading out the contents of KrbPrincipalKey or could write a blob that
 can be successfully decrypted.

 So I was wondering if we might want to prevent both reading and 
 writing
 via LDAP (except via extended operations) and instead use another 
 method
 to determine access patterns.

 As for ipa-getkeytab is everyone ok with tryin the new method first 
 and
 always falling back to the old one (if a password has been provided) ?

 0001
 get_realm_backend() should probably have a comment on why returning 
 NULL
 is ok (either because there is no sdn or because there is no be). It
 appears that things will eventually fail in get_entry_by_principal()

 Instead of adding complex explanations I immediately return with an
 error if get_realm_backend() returns NULL.

 The logic here is correct, it just reads awkwardly. It is probably fine
 as is.

 There appear to be indiscriminate tab indents throughout the patch.
 Please changes these to spaces.

 There are because the coed is old, I do not change the style of a piece
 of code if we are just changing a few lines.
 You need to read the patch in the context of the code to seen it.

 If it were just the problem you alluded to, I wouldn't have called it
 out. I'm referring to tabs in the middle of new code that uses spaces.
 This is most likely the result of copy/paste. Either write all the new
 code to use tabs or match the copy/pasted lines to the surrounding new
 code (my preference).

 Nearly all the new code in ipapwd_setkeytab() uses space indents where
 the surrounding code uses tab indents.
 
 Yes although it looks a bit ugly a long time ago we decided that we'd
 move to space indenting for big blocks of code, or keep tab indent only
 for minor modification. In the hope of eventually converting the
 remaining tabs.
 
 While we are here I decided to split setkeytab along the lines of
 getkeytab too, HTH.
 
 I'm not sure the block comment in is_allowed_to_access_attr() belongs
 there.
 
 Uhhmm now that we check an arbitrary attribute I need to change it. 
 
 Also, a utility function like is_allowed_to_access_attr() would probably
 be handy in upstream 389ds. I might use this in an upcoming token sync
 patch. This is not a requirement of ACK'ing the patch.
 
 The generic 389ds function is slapi_access_allowed() which is normally
 sufficient, is_allowed_to_access_attr() is just a wrapper around some
 additional boilerplate that is not normally needed.
 Anyway feel free to open a bug in 389ds's trac.
 
 0002

 ACK

 One small nitpick, then I too say ACK. In the commit message, the second
 sentence doesn't need a line break.

 I try to keep comments within 72 chars (though sometimes I forget and go
 past till 80), which is why there is a line break there.

 Yeah, it just looks bad when sent over email, which is why I noticed it.

 This didn't get fixed. Add should follow patch. on the same line.
 
 Well, kind of arbitrary, but ok
 
 0003

 Same as patch 002: unnecessary line breaks in the commit message.

 See above.

 Also not fixed. The new set of keys should follow existing ones. on
 the same line.
 
 ok
 
 I think ipapwd_getkeytab() is unnecessarily long. Several sections of it
 could be broken out into functions and would make it much more readable.

 That has already been done :-)
 You should see the original ipa_setkeytab() ...

 I'm not talking about ipapwd_setkeytab(). I'm talking about
 ipapwd_getkeytab(). This is entirely new code. There are very clear
 spots where it could be broken up. I consider this the biggest issue in
 this

Re: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs

2014-06-11 Thread Simo Sorce

On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote:
 Simo Sorce wrote:
  On Tue, 2014-06-10 at 14:27 -0400, Nathaniel McCallum wrote:
  On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote:
  On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote:
  On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote:
  On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote:
  On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote:
  On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote:
  Simo Sorce wrote:
  This patch set is an initial implementation of ticket #3859
 
  It seem to be working fine in my initial testing but I have not yet
  tested all cases.
 
  However I wonted to throw it on the list to get some initial 
  feedback
  about the choices I made wrt access control and ipa-getkeytab flags 
  and
  default behavior.
 
  In particular, the current patch set would require us to make
  host/service keytabs readable by the requesting party (whoever that 
  is,
  admin or host itself) in order to allow it to get back the actual
  keytab. I am not sure this is ideal. Also write access to the 
  keytab is
  still all is needed to allow someone to change it.
 
  Neither is ideal, but it was simpler as a first implementation. In
  particular I think we should allow either permission indipendently, 
  and
  it should be something an admin can change. However I do not like
  allowing normal writes or reads to these attributes, mostly because 
  w/o
  access to the master key nobody can really make sense of actually
  reading out the contents of KrbPrincipalKey or could write a blob 
  that
  can be successfully decrypted.
 
  So I was wondering if we might want to prevent both reading and 
  writing
  via LDAP (except via extended operations) and instead use another 
  method
  to determine access patterns.
 
  As for ipa-getkeytab is everyone ok with tryin the new method first 
  and
  always falling back to the old one (if a password has been 
  provided) ?
 
  0001
  get_realm_backend() should probably have a comment on why returning 
  NULL
  is ok (either because there is no sdn or because there is no be). It
  appears that things will eventually fail in get_entry_by_principal()
 
  Instead of adding complex explanations I immediately return with an
  error if get_realm_backend() returns NULL.
 
  The logic here is correct, it just reads awkwardly. It is probably fine
  as is.
 
  There appear to be indiscriminate tab indents throughout the patch.
  Please changes these to spaces.
 
  There are because the coed is old, I do not change the style of a piece
  of code if we are just changing a few lines.
  You need to read the patch in the context of the code to seen it.
 
  If it were just the problem you alluded to, I wouldn't have called it
  out. I'm referring to tabs in the middle of new code that uses spaces.
  This is most likely the result of copy/paste. Either write all the new
  code to use tabs or match the copy/pasted lines to the surrounding new
  code (my preference).
 
  Nearly all the new code in ipapwd_setkeytab() uses space indents where
  the surrounding code uses tab indents.
  
  Yes although it looks a bit ugly a long time ago we decided that we'd
  move to space indenting for big blocks of code, or keep tab indent only
  for minor modification. In the hope of eventually converting the
  remaining tabs.
  
  While we are here I decided to split setkeytab along the lines of
  getkeytab too, HTH.
  
  I'm not sure the block comment in is_allowed_to_access_attr() belongs
  there.
  
  Uhhmm now that we check an arbitrary attribute I need to change it. 
  
  Also, a utility function like is_allowed_to_access_attr() would probably
  be handy in upstream 389ds. I might use this in an upcoming token sync
  patch. This is not a requirement of ACK'ing the patch.
  
  The generic 389ds function is slapi_access_allowed() which is normally
  sufficient, is_allowed_to_access_attr() is just a wrapper around some
  additional boilerplate that is not normally needed.
  Anyway feel free to open a bug in 389ds's trac.
  
  0002
 
  ACK
 
  One small nitpick, then I too say ACK. In the commit message, the 
  second
  sentence doesn't need a line break.
 
  I try to keep comments within 72 chars (though sometimes I forget and go
  past till 80), which is why there is a line break there.
 
  Yeah, it just looks bad when sent over email, which is why I noticed it.
 
  This didn't get fixed. Add should follow patch. on the same line.
  
  Well, kind of arbitrary, but ok
  
  0003
 
  Same as patch 002: unnecessary line breaks in the commit message.
 
  See above.
 
  Also not fixed. The new set of keys should follow existing ones. on
  the same line.
  
  ok
  
  I think ipapwd_getkeytab() is unnecessarily long. Several sections of 
  it
  could be broken out into functions and would make it much more 
  readable.
 
  That has already been done :-)
  You should see the original ipa_setkeytab() ...
 
  I'm

Re: [Freeipa-devel] [PATCH 0053] Implement OTP token importing

2014-06-11 Thread Nathaniel McCallum

On Wed, 2014-06-11 at 14:24 +0200, Jan Cholasta wrote:
Hi,

On 13.5.2014 18:40, Nathaniel McCallum wrote:
On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote:
This patch adds support for importing tokens using RFC 6030 key
container files. This includes decryption support. For sysadmin sanity,
any tokens which fail to add will be written to the output file for
examination. The main use case here is where a small subset of a large
set of tokens fails to validate or add. Using the output file, the
sysadmin can attempt to recover these specific tokens.

This code is implemented as a server-side script. However, it doesn't
actually need to run on the server. This was done because importing is
an odd fit for the IPA command framework:
1. We need to write an output file.
2. The operation may be long-running (thousands of tokens).
3. Only admins need to perform this task and it only happens
infrequently.

I forgot to put the link to the ticket in the commit message. Fixed.

1) I think you should initialize NSS in ipa_otptoken_import.py, not in
the ipa-otptoken-import script.

Fixed.

2) The pep8 tool reports a lot of errors in ipa_otptoken_import.py.

Fixed (mostly). The remaining output from pep8 is, I think, entirely
justifiable.

3) Other error messages are in the form message: %s, I think this one
should use that form as well:

+if encoding != 'DECIMAL':
+raise ValidationError('Unsupported encoding (%s)!' % encoding)

Fixed.

4) This is not right:

+except:
+self.log.warn(Error adding token: +
str(sys.exc_info()[1]))

I think it should be something like this instead:

except ValidationError, e:
self.log.warn(Error adding token: %s, e)

Fixed.

5) There is no man page for ipa-otptoken-import.

TODO (tomorrow).

6) Output file is created even when ipa-otptoken-import fails with
Unable to connect to LDAP! Did you kinit? and other initialization
errors, which makes subsequent ipa-otptoken-import fail with Output
file already exists!.

Fixed.

7) When a key is specified by reference in Key/KeyReference instead of
directly in Key/Data/Secret like in
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure4.xml,

import fails with Key not found in token!. I would expect a different
error message.

This error is now: Referenced keys are not supported!

8) Importing
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure5.xml

produces this output:

/usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307:

FutureWarning: The behavior of this method will change in future
versions. Use specific 'len(elem)' or 'elem is not None' test instead.
if data.get('pinpolicy', None):
Error adding token: 'NoneType' object has no attribute 'strip'

This now states:
Error adding token: PINPolicy policy not supported!
Error adding token: Unsupported token type!

9) Using an arbitrary file in -k produces this output:

(SEC_ERROR_INVALID_KEY) The key does not support the requested operation.
Traceback (most recent call last):
File /usr/sbin/ipa-otptoken-import, line 29, in module
nss.nss_shutdown()
nss.error.NSPRError: (SEC_ERROR_BUSY) NSS could not shutdown. Objects
are still in use.

What do you mean by arbitrary file? A file that is not the key?
Like /dev/null? I'm not able to reproduce this.

10) Importing
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure7.xml

and
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-figure8.xml

produces this output:

Error adding token: object of type 'NoneType' has no len()

Import fails with:
Derived keys are not currently supported!
or
X.509 keys are not currently supported!

It would be nice to support these in the future.

11) Importing
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-all.xml

or
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-all-signed.xml

produces this output:

/usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:304:

FutureWarning: The behavior of this method will change in future
versions. Use specific 'len(elem)' or 'elem is not None' test instead.
if data.get('maxtransact', None):
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307:

FutureWarning: The behavior of this method will change in future
versions. Use specific 'len(elem)' or 'elem is not None' test instead.
if data.get('pinpolicy', None):

Both of these now output:
Error adding token: NumberOfTransactions policy not supported!

12) Importing
http://git.savannah.gnu.org/cgit/oath-toolkit.git/tree/pskctool/tests/pskc-invalid.xml

succeeds, but it should fail.

This now errors with:
PSKC file is invalid!

13) Importing

Re: [Freeipa-devel] user certificates

2014-06-11 Thread Fraser Tweedale

On Wed, Jun 11, 2014 at 08:55:20AM -0400, John Dennis wrote:
 On 06/11/2014 04:02 AM, Fraser Tweedale wrote:
  There are other use cases for user certificates, e.g. client
  authentication for HTTP or other network services.  Perhaps you know
  of others - in which case let us know.
 
 802.11 wireless authentication using EAP-TLS
 
 A common discussion on the RADIUS mailing lists is the desire to deploy
 using EAP-TLS but the difficulty of provisioning user certs is always
 the stumbling block.
 

Thanks John,

I've created http://www.freeipa.org/page/User_certificate_use_cases
to collect and discuss these use cases.

Fraser

 -- 
 John

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] user certificates

2014-06-11 Thread Dmitri Pal


On 06/11/2014 09:18 PM, Fraser Tweedale wrote:

On Wed, Jun 11, 2014 at 08:55:20AM -0400, John Dennis wrote:

On 06/11/2014 04:02 AM, Fraser Tweedale wrote:

There are other use cases for user certificates, e.g. client
authentication for HTTP or other network services.  Perhaps you know
of others - in which case let us know.

802.11 wireless authentication using EAP-TLS

A common discussion on the RADIUS mailing lists is the desire to deploy
using EAP-TLS but the difficulty of provisioning user certs is always
the stumbling block.


Thanks John,

I've created http://www.freeipa.org/page/User_certificate_use_cases
to collect and discuss these use cases.


I think it is important to differ short term and long term certificates 
for users.
The long term certificates are used for authentication and signing. They 
are put on devices like smart cards. They need to be associated with the 
user in the back end. They can be revoked.
The short lived certificates do not need to be recorded on the server 
side. They are just issued and since they do not live long there is no 
need to record them in the back end or to try to revoke them. This IMO a 
crucial difference.


For now we focus on the long living certificates for hosts, services, 
devices  and short lived certificates for any identity.
IMO long lived certs for users is a separate big use case that we 
currently should set aside and solve after we solve the other use cases.




Fraser


--
John

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

46 matches

Mail list logo