Re: [Freeipa-devel] [PATCH] 902 Don't allow empty default object classes
On Wed, 2011-11-09 at 09:23 +0200, Alexander Bokovoy wrote: > On Tue, 08 Nov 2011, Rob Crittenden wrote: > > > Don't allow one to set a blank list of default objectclasses in > > cn=ipaconfig. > > > ACK > Pushed to master, ipa-2-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 902 Don't allow empty default object classes
On Tue, 08 Nov 2011, Rob Crittenden wrote: > Don't allow one to set a blank list of default objectclasses in > cn=ipaconfig. > ACK -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Freeipa-users] OpenSSH integration - known_hosts
On 11/08/2011 06:35 PM, Simo Sorce wrote: > On Tue, 2011-11-08 at 17:57 -0500, Dmitri Pal wrote: >> On 11/08/2011 02:56 PM, Dan Scott wrote: >>> Hi, >>> >>> This is a great feature. It feels like I'm always re-installing VMs >>> and having to remove old SSH keys and re-accept new ones. >>> >>> One feature I'd like is to have this working cross-realm. We have 2 >>> IPA realms here and it would be great if I could configure SSSD to >>> check the local realm if I'm SSHing to a local PC and to check the >>> other IPA server(s) if my SSH target is part of the other realm. Even >>> better if it could do this without explicit configuration. >>> >>> Do you think it would be possible to do this securely? >> When we start to support Cross Realm Kerberos Trusts for IPA to IPA I >> think this would be doable but then I do not think the ssh host keys >> will be used (needed). Simo, am I correct? > We do not have the GSSAPI key exchange patches in OpenSSH. With those > the ssh host key is not necessary when using GSSAPI auth, even in the > same realm. > > But when you want to use ssh host keys, across realm kerberos trust is > not going to help. > > In order to validate keys from different realms I guess we could use > DNSSEC where the signatures of one realm are trusted by the other. > Then by storing ssh host keys as DNS fields a different domain could > still trust those keys. This works only for enrolled hosts though, I > guess. Or at least only for hosts in DNS domains that are controlled by > IPA. For hosts in other DNS domains we cannot distribute keys through > DNS. > If that is necessary then we would have to define some sort of protocol > to allow fetching of keys from one domain to the other. > We could use a mechanism similar to what we will need to implement for > sid2name resolution for windows domain trusts. Where the IPA server > becomes a proxy to request host keys from other domains. > > Bottom line, we can come up with something but it is not scoped yet. And > needs some more thinking so that we put in place something that scales > well. > > Simo. > Ok: https://fedorahosted.org/freeipa/ticket/2081 -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Freeipa-users] OpenSSH integration - known_hosts
On Tue, 2011-11-08 at 17:57 -0500, Dmitri Pal wrote: > On 11/08/2011 02:56 PM, Dan Scott wrote: > > Hi, > > > > This is a great feature. It feels like I'm always re-installing VMs > > and having to remove old SSH keys and re-accept new ones. > > > > One feature I'd like is to have this working cross-realm. We have 2 > > IPA realms here and it would be great if I could configure SSSD to > > check the local realm if I'm SSHing to a local PC and to check the > > other IPA server(s) if my SSH target is part of the other realm. Even > > better if it could do this without explicit configuration. > > > > Do you think it would be possible to do this securely? > > When we start to support Cross Realm Kerberos Trusts for IPA to IPA I > think this would be doable but then I do not think the ssh host keys > will be used (needed). Simo, am I correct? We do not have the GSSAPI key exchange patches in OpenSSH. With those the ssh host key is not necessary when using GSSAPI auth, even in the same realm. But when you want to use ssh host keys, across realm kerberos trust is not going to help. In order to validate keys from different realms I guess we could use DNSSEC where the signatures of one realm are trusted by the other. Then by storing ssh host keys as DNS fields a different domain could still trust those keys. This works only for enrolled hosts though, I guess. Or at least only for hosts in DNS domains that are controlled by IPA. For hosts in other DNS domains we cannot distribute keys through DNS. If that is necessary then we would have to define some sort of protocol to allow fetching of keys from one domain to the other. We could use a mechanism similar to what we will need to implement for sid2name resolution for windows domain trusts. Where the IPA server becomes a proxy to request host keys from other domains. Bottom line, we can come up with something but it is not scoped yet. And needs some more thinking so that we put in place something that scales well. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 903 normalize paths in certmonger
There are times we need to hunt through the certmonger request files
trying (such as trying to stop tracking a cert). One criteria is the
cert database and they need to match exactly. We weren't normalizing
this so something as simple as a trailing slash would cause a match to fail.
Normalize both values to address this.
rob
>From d4cd8ef04827f7b28df23f252d56b5965f89af16 Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Tue, 8 Nov 2011 18:30:44 -0500
Subject: [PATCH] Use absolute paths when trying to find certmonger request
id.
The value stored in certmonger is not guaranteed to be normalized
nor is the value passed-in (could be a relative path and may or not
contain trailing slash). We do direct string compares so they need
to match exactly or we won't find the request.
https://fedorahosted.org/freeipa/ticket/1942
---
ipapython/certmonger.py | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/ipapython/certmonger.py b/ipapython/certmonger.py
index 1ed9076..3517be3 100644
--- a/ipapython/certmonger.py
+++ b/ipapython/certmonger.py
@@ -29,6 +29,9 @@ from ipapython import ipautil
REQUEST_DIR='/var/lib/certmonger/requests/'
CA_DIR='/var/lib/certmonger/cas/'
+# Normalizer types for critera in get_request_id()
+NPATH = 1
+
def find_request_value(filename, directive):
"""
Return a value from a certmonger request file for the requested directive
@@ -83,7 +86,7 @@ def get_request_id(criteria):
through all the request files. An alternative would be to parse the
ipa-getcert list output but this seems cleaner.
-criteria is a tuple of key/value pairs to search for. The more specific
+criteria is a tuple of key/value/type to search for. The more specific
the better. An error is raised if multiple request_ids are returned for
the same criteria.
@@ -95,8 +98,10 @@ def get_request_id(criteria):
fileList=os.listdir(REQUEST_DIR)
for file in fileList:
match = True
-for (key, value) in criteria:
+for (key, value, valtype) in criteria:
rv = find_request_value('%s/%s' % (REQUEST_DIR, file), key)
+if rv and valtype == NPATH:
+rv = os.path.abspath(rv)
if rv is None or rv.rstrip() != value:
match = False
break
@@ -175,7 +180,7 @@ def cert_exists(nickname, secdir):
the database.
"""
args = ["/usr/bin/certutil", "-L",
- "-d", secdir,
+ "-d", os.path.abspath(secdir),
"-n", nickname
]
(stdout, stderr, rc) = ipautil.run(args, raiseonerr=False)
@@ -193,10 +198,10 @@ def start_tracking(nickname, secdir, password_file=None):
This assumes that certmonger is already running.
"""
-if not cert_exists(nickname, secdir):
+if not cert_exists(nickname, os.path.abspath(secdir)):
raise RuntimeError('Nickname "%s" doesn\'t exist in NSS database "%s"' % (nickname, secdir))
args = ["/usr/bin/ipa-getcert", "start-tracking",
-"-d", secdir,
+"-d", os.path.abspath(secdir),
"-n", nickname]
if password_file:
args.append("-p")
@@ -216,7 +221,7 @@ def stop_tracking(secdir, request_id=None, nickname=None):
raise RuntimeError('Both request_id and nickname are missing.')
if nickname:
# Using the nickname find the certmonger request_id
-criteria = (('cert_storage_location','%s' % secdir),('cert_nickname', '%s' % nickname))
+criteria = (('cert_storage_location','%s' % os.path.abspath(secdir), NPATH),('cert_nickname', '%s' % nickname, None))
try:
request_id = get_request_id(criteria)
if request_id is None:
@@ -236,7 +241,7 @@ def stop_tracking(secdir, request_id=None, nickname=None):
args.append('-n')
args.append(nickname)
args.append('-d')
-args.append(secdir)
+args.append(os.path.abspath(secdir))
(stdout, stderr, returncode) = ipautil.run(args)
--
1.7.6.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Freeipa-users] OpenSSH integration - known_hosts
On 11/08/2011 02:56 PM, Dan Scott wrote: > Hi, > > This is a great feature. It feels like I'm always re-installing VMs > and having to remove old SSH keys and re-accept new ones. > > One feature I'd like is to have this working cross-realm. We have 2 > IPA realms here and it would be great if I could configure SSSD to > check the local realm if I'm SSHing to a local PC and to check the > other IPA server(s) if my SSH target is part of the other realm. Even > better if it could do this without explicit configuration. > > Do you think it would be possible to do this securely? When we start to support Cross Realm Kerberos Trusts for IPA to IPA I think this would be doable but then I do not think the ssh host keys will be used (needed). Simo, am I correct? > Dan > > On Tue, Nov 8, 2011 at 12:38, Jan Zelenı wrote: >> Hello everyone, >> there is a new effort in IPA and SSSD teams and that is SSH key integration >> in >> both parts of SSSD-IPA infrastructure. We've put together some basic plans >> and >> now we would like to know your opinion. >> >> Note that this is just shortened version to make it easier to read. It >> doesn't >> contain every bit of information about the design. For full version see >> https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration >> >> Problems: >> = >> * the known_hosts file becomes outdated as machines get new host keys (e.g. >> re- >> installed systems in virtualized environment) >> * the user accepts any host key of the remote host without validating its >> authenticity >> >> >> Solution: >> = >> Instead of checking stale known_hosts file, provide a dynamic mechanism to >> lookup and deliver the public ssh key of the remote host to the client and >> use >> it for validation of the remote host identity. The dynamic mechanism would >> imply that no action is needed from the user because the source of the >> retrieved key is trusted. >> >> >> Limitations: >> >> It is out of scope of this work to solve the problem in general. We propose a >> solution for following use case: >> >> Client host is a managed host meaning that it has SSSD installed and it is >> joined an IPA domain. It also has OpenSSH patched to interact with SSSD to >> get >> the information about the remote host >> >> Other UNIX machines or Windows machines as SSH clients are out of the scope >> of >> the current project. For the client hosts that can not be managed but can >> access IPA via the standard LDAP tools we will provide documentation on how >> to >> construct the content of the known_hosts file by querying LDAP server and >> saving the results. >> >> The remote host can be a managed (joined IPA domain via SSSD) or an unmanaged >> host. IPA server needs to provide a way to create entries for any managed and >> unmanaged hosts and store public keys for those hosts in that entries. >> >> What would change in IPA: >> = >> * external host would have entries with the possibility of storing their >> public keys >> * new mechanism to work with keys through UI and CLI >> * host key fingerprints would be stored in SSHFP DNS records for each host >> joined in IPA domain >> >> What would change on the client: >> >> * SSSD would fetch and cache host public keys from IPA >> * joining to IPA domain would upload host public key >> * ssh client would communicate with SSSD, probably through ssh-agent, to >> check >> if the remote host is known >> >> It is still a question whether the solution is sufficient enough to address >> the >> needs and pains of the real deployments or other technologies outside the >> proposed should be used later (or instead). >> >> -- >> Thank you >> Jan Zeleny >> >> Red Hat Software Engineer >> Brno, Czech Republic >> >> ___ >> Freeipa-users mailing list >> freeipa-us...@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 902 Don't allow empty default object classes
Don't allow one to set a blank list of default objectclasses in
cn=ipaconfig.
rob
>From 0d486f34eaf68384151a809da5d5d5749095f7d7 Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Tue, 8 Nov 2011 17:04:26 -0500
Subject: [PATCH] Don't allow default objectclass list to be empty.
https://fedorahosted.org/freeipa/ticket/1945
---
ipalib/plugins/config.py |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py
index 9bed5d8..332eea1 100644
--- a/ipalib/plugins/config.py
+++ b/ipalib/plugins/config.py
@@ -220,6 +220,9 @@ class config_mod(LDAPUpdate):
for (attr, obj) in (('ipauserobjectclasses', 'user'),
('ipagroupobjectclasses', 'group')):
if attr in entry_attrs:
+if not entry_attrs[attr]:
+raise errors.ValidationError(name=attr,
+error=_('May not be empty'))
objectclasses = list(set(entry_attrs[attr] \
+ self.api.Object[obj].possible_objectclasses))
new_allowed_attrs = ldap.get_allowed_attributes(objectclasses,
--
1.7.6.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Freeipa-users] OpenSSH integration - known_hosts
Hi, This is a great feature. It feels like I'm always re-installing VMs and having to remove old SSH keys and re-accept new ones. One feature I'd like is to have this working cross-realm. We have 2 IPA realms here and it would be great if I could configure SSSD to check the local realm if I'm SSHing to a local PC and to check the other IPA server(s) if my SSH target is part of the other realm. Even better if it could do this without explicit configuration. Do you think it would be possible to do this securely? Dan On Tue, Nov 8, 2011 at 12:38, Jan Zelenı wrote: > Hello everyone, > there is a new effort in IPA and SSSD teams and that is SSH key integration in > both parts of SSSD-IPA infrastructure. We've put together some basic plans and > now we would like to know your opinion. > > Note that this is just shortened version to make it easier to read. It doesn't > contain every bit of information about the design. For full version see > https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration > > Problems: > = > * the known_hosts file becomes outdated as machines get new host keys (e.g. > re- > installed systems in virtualized environment) > * the user accepts any host key of the remote host without validating its > authenticity > > > Solution: > = > Instead of checking stale known_hosts file, provide a dynamic mechanism to > lookup and deliver the public ssh key of the remote host to the client and use > it for validation of the remote host identity. The dynamic mechanism would > imply that no action is needed from the user because the source of the > retrieved key is trusted. > > > Limitations: > > It is out of scope of this work to solve the problem in general. We propose a > solution for following use case: > > Client host is a managed host meaning that it has SSSD installed and it is > joined an IPA domain. It also has OpenSSH patched to interact with SSSD to get > the information about the remote host > > Other UNIX machines or Windows machines as SSH clients are out of the scope of > the current project. For the client hosts that can not be managed but can > access IPA via the standard LDAP tools we will provide documentation on how to > construct the content of the known_hosts file by querying LDAP server and > saving the results. > > The remote host can be a managed (joined IPA domain via SSSD) or an unmanaged > host. IPA server needs to provide a way to create entries for any managed and > unmanaged hosts and store public keys for those hosts in that entries. > > What would change in IPA: > = > * external host would have entries with the possibility of storing their > public keys > * new mechanism to work with keys through UI and CLI > * host key fingerprints would be stored in SSHFP DNS records for each host > joined in IPA domain > > What would change on the client: > > * SSSD would fetch and cache host public keys from IPA > * joining to IPA domain would upload host public key > * ssh client would communicate with SSSD, probably through ssh-agent, to check > if the remote host is known > > It is still a question whether the solution is sufficient enough to address > the > needs and pains of the real deployments or other technologies outside the > proposed should be used later (or instead). > > -- > Thank you > Jan Zeleny > > Red Hat Software Engineer > Brno, Czech Republic > > ___ > Freeipa-users mailing list > freeipa-us...@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 901 remove has_upg() and has_managed_entries()
These functions are leftovers from when the managed entries plugin was
being developed and not widely available. They are no longer needed.
rob
>From 3159ac686fa09b747d3908b8497254bce1b8f337 Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Tue, 8 Nov 2011 11:33:46 -0500
Subject: [PATCH] Remove calls to has_upg() and has_managed_entries()
At one point in time we couldn't depend on the 389-ds having
the managed entries plugin so this code was added to support
both versions. It is no longer needed.
https://fedorahosted.org/freeipa/ticket/1242
---
ipalib/plugins/user.py |2 +-
ipaserver/install/dsinstance.py | 30 --
ipaserver/plugins/ldap2.py | 22 --
3 files changed, 1 insertions(+), 53 deletions(-)
diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index 273c68f..d0dd8ce 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -405,7 +405,7 @@ class user_add(LDAPCreate):
if 'gidnumber' not in entry_attrs:
# gidNumber wasn't specified explicity, find out what it should be
-if not options.get('noprivate', False) and ldap.has_upg():
+if not options.get('noprivate', False):
# User Private Groups - uidNumber == gidNumber
entry_attrs['gidnumber'] = entry_attrs['uidnumber']
else:
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 995877c..15de54e 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -110,26 +110,6 @@ def check_ports():
def is_ds_running(server_id=''):
return ipaservices.knownservices.dirsrv.is_running(instance_name=server_id)
-def has_managed_entries(host_name, dm_password):
-"""Check to see if the Managed Entries plugin is available"""
-ldapuri = 'ldap://%s' % ipautil.format_netloc(host_name)
-conn = None
-try:
-conn = ldap2(shared_instance=False, ldap_uri=ldapuri, base_dn='cn=config')
-conn.connect(bind_dn='cn=Directory Manager', bind_pw=dm_password)
-(dn, attrs) = conn.get_entry('cn=Managed Entries,cn=plugins',
- ['*'], time_limit=2, size_limit=3000)
-return True
-except errors.NotFound:
-return False
-except errors.ExecutionError, e:
-logging.critical("Could not connect to the Directory Server on %s" % host_name)
-raise e
-finally:
-if conn.isconnected():
-conn.disconnect()
-
-
INF_TEMPLATE = """
[General]
FullMachineName= $FQHN
@@ -457,8 +437,6 @@ class DsInstance(service.Service):
self._ldap_mod("unique-attributes.ldif", self.sub_dict)
def __config_uidgid_gen(self):
-if not has_managed_entries(self.fqdn, self.dm_password):
-raise errors.NotFound(reason='Missing Managed Entries Plugin')
self._ldap_mod("dna.ldif", self.sub_dict)
def __add_master_entry(self):
@@ -488,23 +466,15 @@ class DsInstance(service.Service):
self._ldap_mod("lockout-conf.ldif")
def __repoint_managed_entries(self):
-if not has_managed_entries(self.fqdn, self.dm_password):
-raise errors.NotFound(reason='Missing Managed Entries Plugin')
self._ldap_mod("repoint-managed-entries.ldif", self.sub_dict)
def __managed_entries(self):
-if not has_managed_entries(self.fqdn, self.dm_password):
-raise errors.NotFound(reason='Missing Managed Entries Plugin')
self._ldap_mod("managed-entries.ldif", self.sub_dict)
def __user_private_groups(self):
-if not has_managed_entries(self.fqdn, self.dm_password):
-raise errors.NotFound(reason='Missing Managed Entries Plugin')
self._ldap_mod("user_private_groups.ldif", self.sub_dict)
def __host_nis_groups(self):
-if not has_managed_entries(self.fqdn, self.dm_password):
-raise errors.NotFound(reason='Missing Managed Entries Plugin')
self._ldap_mod("host_nis_groups.ldif", self.sub_dict)
def __add_enrollment_module(self):
diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py
index 5c40182..05276e6 100644
--- a/ipaserver/plugins/ldap2.py
+++ b/ipaserver/plugins/ldap2.py
@@ -702,28 +702,6 @@ class ldap2(CrudBackend, Encoder):
else:
return self.schema
-def has_upg(self):
-"""Returns True/False whether User-Private Groups are enabled.
- This is determined based on whether the UPG Template exists.
-"""
-
-upg_dn = str(DN('cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc', api.env.basedn))
-
-try:
-upg_entry = self.conn.search_s(
-upg_dn,
-_ldap.SCOPE_BASE,
-attrlist=['*']
-)[0]
-disable_attr = '(objectclass=disable)'
-if 'originfilter' in upg_entry[1]:
-org_filter = upg_entry[1]['originfilter']
-
[Freeipa-devel] [PATCH] the 'Keytab:' field in "ipa user-show" output is misleading
https://fedorahosted.org/freeipa/ticket/1961
The 'Keytab' filed in output of all 'user-*' commands was changed to
'Kerberos keys available'. In order to do this change for 'user-*'
commands only, the flag 'has_keytab' had to be removed from common
output parametrs in ipalib/baseldap.py. This change also affected the
host.py and service.py, where the 'has_keytab' flag was added to their
local output params. Both host.py and service.py holds the old field
caption - 'Keytab' - because of compatibility with older clients.
--
Regards,
Ondrej Hamada
FreeIPA team
jabber:oh...@jabbim.cz
IRC: ohamada
From 77d719d184126e85c27b20db1a3735e7d14b83f2 Mon Sep 17 00:00:00 2001
From: Ondrej Hamada
Date: Tue, 8 Nov 2011 19:12:48 +0100
Subject: [PATCH] [PATCH] the 'Keytab:' field in "ipa user-show" output is
misleading
---
ipalib/plugins/baseldap.py |3 ---
ipalib/plugins/host.py |3 +++
ipalib/plugins/service.py |5 +
ipalib/plugins/user.py | 14 ++
4 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 88f312998d27ecd8311eb4204c95e1ca212afeb2..4fd5fe4a1e7ff2d8fac7d3a65379b4ae0c5eb554 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -36,9 +36,6 @@ from ipalib.util import json_serialize
from ipalib.dn import *
global_output_params = (
-Flag('has_keytab',
-label=_('Keytab'),
-),
Flag('has_password',
label=_('Password'),
),
diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py
index 0f3f91565cedb699726421ec00cb8f7a93b821bb..6557880aa82598857251f3d8b80e6d3b326fbca6 100644
--- a/ipalib/plugins/host.py
+++ b/ipalib/plugins/host.py
@@ -162,6 +162,9 @@ def remove_fwd_ptr(ipaddr, host, domain, recordtype):
pass
host_output_params = (
+Flag('has_keytab',
+label=_('Keytab'),
+),
Str('managedby_host',
label='Managed by',
),
diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py
index 048a6b4f04b761131108874fbd09962be33e8a80..dad3ded434d241ae55e1352889c577ba1a08d8c4 100644
--- a/ipalib/plugins/service.py
+++ b/ipalib/plugins/service.py
@@ -84,6 +84,9 @@ EXAMPLES:
""")
output_params = (
+Flag('has_keytab',
+label=_('Keytab'),
+),
Str('managedby_host',
label='Managed by',
),
@@ -358,6 +361,7 @@ class service_find(LDAPSearch):
member_attributes = ['managedby']
takes_options = LDAPSearch.takes_options
has_output_params = LDAPSearch.has_output_params + output_params
+
def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *args, **options):
# lisp style!
custom_filter = '(&(objectclass=ipaService)' \
@@ -392,6 +396,7 @@ class service_show(LDAPRetrieve):
doc=_('file to store certificate in'),
),
)
+has_output_params = LDAPRetrieve.has_output_params + output_params
def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
self.obj.get_password_attributes(ldap, dn, entry_attrs)
diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index 273c68fb2457da7493227ae820c263ebf7598327..d3e63ef9a7bcf98d0bd34396b144134be38c17c3 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -68,6 +68,12 @@ EXAMPLES:
NO_UPG_MAGIC = '__no_upg__'
+user_output_params = (
+Flag('has_keytab',
+label=_('Kerberos keys available'),
+),
+ )
+
def validate_nsaccountlock(entry_attrs):
if 'nsaccountlock' in entry_attrs:
nsaccountlock = entry_attrs['nsaccountlock']
@@ -352,6 +358,8 @@ class user_add(LDAPCreate):
msg_summary = _('Added user "%(value)s"')
+has_output_params = LDAPCreate.has_output_params + user_output_params
+
takes_options = LDAPCreate.takes_options + (
Flag('noprivate',
cli_name='noprivate',
@@ -477,6 +485,8 @@ class user_mod(LDAPUpdate):
msg_summary = _('Modified user "%(value)s"')
+has_output_params = LDAPUpdate.has_output_params + user_output_params
+
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
if 'mail' in entry_attrs:
entry_attrs['mail'] = self.obj._normalize_email(entry_attrs['mail'])
@@ -498,6 +508,7 @@ class user_find(LDAPSearch):
__doc__ = _('Search for users.')
member_attributes = ['memberof']
+has_output_params = LDAPSearch.has_output_params + user_output_params
takes_options = LDAPSearch.takes_options + (
Flag('whoami',
@@ -532,6 +543,8 @@ api.register(user_find)
class user_show(LDAPRetrieve):
__doc__ = _('Display information about a user.')
+has_output_params = LDAPRetrieve.has_output_params + user_output_params
+
def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
convert_nsaccountlock(entry_attrs)
self.obj._convert_manager(entry_attrs, **options)
@@ -566,6 +579,7 @@ class user_enable(LDAPQuery):
__doc
[Freeipa-devel] Tomcat Realms and Directory Server
One issue I have been looking at recently is how to integrate PKI and IPA at the auth level while keeping a clean separation. We can extract the authentication from the servlet code, so it is purely a matter of configuring the Tomcat instance Realm. I wrote up a Proof of concept for just doing pure LDAP using simple bind, which is not a bad starting point. http://adam.younglogic.com/2011/11/tomcat-simple-ipa/ We want to continue this approach, but use a more secure authentication method. We won't be using basic auth, and we won't be using simple bind. There are two forms of authentication we want to support: Client Certificates and Kerberos. Certificates will work as they do now, and Kerberos will be for passing through user credentials from IPA, through HTTP to CS. In both cases, the data that backs it will be stored in the DS instance. Tomcat has a class classed a CombinedRealm: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm That might support stacking Certificate and Kerberos auth on top of each other. The Realm will then delegate to LDAP for extracting the Roles. http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm Kerberos is typically done using a JAAS Realm. I have to admit I don't really like the fact that we have to modify the JVM startup to do so, it is not really that big of a deal. I was also not a fan of setting the Realm up as a single service ticket until Simo informed me that the Browser NEGOTIATE mechanism assumes that the Service ticket is going to be Named HTTP. This means that for Proxied implementations, to include IPA, we will have to share the Service Principal Identity with the Apache HTTPD server. http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm However, once you start digging in, you will find that the solutions are suboptimal. It turns out that the Negotiate auth-method has only very recently been supported, and that is only on Tomcat7. The best resource I have found on the options for a custom realm is here: http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos and the most likely option http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule We really want a mix of the KRB5Login Module and the JNDIRealm. That seems to be what is described here: http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with Tomcat-7. I suspect that the CombinedRealm approach will not support falling back from one auth-method to another: I've been looking and have not see it specified that you can put multiple auth-method entries inside a login-config in the web.xml. Ideally, we would attempt a Certificate based authentication first, and then fall back to Negotiate. However, we can say that a given deployment is going to be either Kerberos or Client Certificate, and swap out the configuration at the Tomcat level. I don't like that nearly as much. The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback talks about how to do Client Cert with a fallback to Form based authentication. We'd want to do Client Cert with a fallback to Krb5. This is using what is called a Valve. In Tomcat 6 and 7 valves have been deprecated in favor of Filters. The general approach is the same. I'd like to keep the idea of the Realm as the primary approach. If we do have to build a custom Realm, and I suspect that we will, we might want to spin it off into its own package, or submit it for Inclusion in Tomcat 7 upstream. It seems that the PKI approach has been to Bind as Directory Manager. What I would like to target moving forward is that the Bind is done as the user making the web request. For managed operations that require a higher level of authentication, we use the concept of queues like we do now. The threads that manage those queue will use a Principal with a higher level of authorization: not "Directory Manger", but perhaps "CA Manager" which is a user we create that manages the CA subtree in the Directory server. For a Dogtag deployment without IPA, the CA Manger would have write privileged on the Identity subtree. For integrated deployments, IPA would have its own principal "IPA Manager" that would not have read or write capabilities in the CA Subtree. DRM, TKS and other subsytems would in turn also get their own Manager users, and they would only have permissions to manage their own trees: we will need to clear up which gets read and write permissions on which other subtrees. Directory Manager would be limited to performing operations that effect the entire DS instance: Setup and Replication. The Directory Manager, CA Manager, IPA manager users should be binding with a certificate or a keytab, not with a cleartext password. ___ Freeipa-devel mailing list Freeipa-devel@re
[Freeipa-devel] OpenSSH integration - authorized_keys
Hello everyone, this is a follow-up on the email on OpenSSH integration - known_host. It describes another scenario we want to address in the process of integrating OpenSSH to SSSD-IPA infrastructure - user public keys and their central management. As in the previous email, we would also like to know your opinion. Note that this is just shortened version to make it easier to read. It doesn't contain every bit of information about the design. For full version see https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration Problems: = * how to distribute keys for new users / regenerated keys through the domain. The authorized_keys is probably not an option, we also want to cover use case when home directories are remote and not mounted on the server. * user may want to log on to the remote server using different account. We need to determine if he is allowed to impersonate that account Solution: = Similarly to openssh-lpk, the solution is to centrally manage and store user public keys in the IPA server and deliver them to the host for validation when user accesses that host. In the central server provide a way to define which account can do impersonation of which other accounts. Optionally add a way to represent special service accounts that are not full user accounts but can be logged as via ssh (stretch goal). What would change on IPA: = * user entry will have additional multi-valued attribute for storing public keys. Unlike in openssh-lpk, this attribute will store what keys the user has, not who can impersonate him. * user entry would also have a multi-valued attribute containg DNs of users he can impersonate * new mechanisms to work with account public keys and impersonation via UI and CLI * HBAC rules would be extended to cover impersonation * provide an LDAP control to get a list of ssh keys that correspond to accounts that can impersonate a particular account in one operation. On the client side: === * SSSD would fetch (and cache?) user public keys from IPA * new SSSD client would fetch user public keys from SSSD * use SSH agent feature to get user public key from an output of the SSSD client -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] OpenSSH integration - known_hosts
Hello everyone, there is a new effort in IPA and SSSD teams and that is SSH key integration in both parts of SSSD-IPA infrastructure. We've put together some basic plans and now we would like to know your opinion. Note that this is just shortened version to make it easier to read. It doesn't contain every bit of information about the design. For full version see https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration Problems: = * the known_hosts file becomes outdated as machines get new host keys (e.g. re- installed systems in virtualized environment) * the user accepts any host key of the remote host without validating its authenticity Solution: = Instead of checking stale known_hosts file, provide a dynamic mechanism to lookup and deliver the public ssh key of the remote host to the client and use it for validation of the remote host identity. The dynamic mechanism would imply that no action is needed from the user because the source of the retrieved key is trusted. Limitations: It is out of scope of this work to solve the problem in general. We propose a solution for following use case: Client host is a managed host meaning that it has SSSD installed and it is joined an IPA domain. It also has OpenSSH patched to interact with SSSD to get the information about the remote host Other UNIX machines or Windows machines as SSH clients are out of the scope of the current project. For the client hosts that can not be managed but can access IPA via the standard LDAP tools we will provide documentation on how to construct the content of the known_hosts file by querying LDAP server and saving the results. The remote host can be a managed (joined IPA domain via SSSD) or an unmanaged host. IPA server needs to provide a way to create entries for any managed and unmanaged hosts and store public keys for those hosts in that entries. What would change in IPA: = * external host would have entries with the possibility of storing their public keys * new mechanism to work with keys through UI and CLI * host key fingerprints would be stored in SSHFP DNS records for each host joined in IPA domain What would change on the client: * SSSD would fetch and cache host public keys from IPA * joining to IPA domain would upload host public key * ssh client would communicate with SSSD, probably through ssh-agent, to check if the remote host is known It is still a question whether the solution is sufficient enough to address the needs and pains of the real deployments or other technologies outside the proposed should be used later (or instead). -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 162 Fix coverity issues in client CLI tools
This patch fixes 2 coverity issues:
* ipa-client/config.c: CID 11090: Resource leak
* ipa-client/ipa-getkeytab.c: CID 11018: Unchecked return value
https://fedorahosted.org/freeipa/ticket/2035
>From 828dc2c448707fc48da97a2254d19db04e76fde2 Mon Sep 17 00:00:00 2001
From: Martin Kosek
Date: Tue, 8 Nov 2011 17:59:45 +0100
Subject: [PATCH] Fix coverity issues in client CLI tools
This patch fixes 2 coverity issues:
* ipa-client/config.c: CID 11090: Resource leak
* ipa-client/ipa-getkeytab.c: CID 11018: Unchecked return value
https://fedorahosted.org/freeipa/ticket/2035
---
ipa-client/config.c| 20
ipa-client/ipa-getkeytab.c | 10 +-
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/ipa-client/config.c b/ipa-client/config.c
index 493d740207ffca4275f512fad97d40e4f1e8fa05..95bd5c285cc785b354386ad41a73960888107af5 100644
--- a/ipa-client/config.c
+++ b/ipa-client/config.c
@@ -45,28 +45,29 @@
char *
read_config_file(const char *filename)
{
-int fd;
+int fd = -1;
struct stat st;
-char *data, *dest;
+char *data = NULL;
+char *dest;
size_t left;
fd = open(filename, O_RDONLY);
if (fd == -1) {
fprintf(stderr, _("cannot open configuration file %s\n"), filename);
-return NULL;
+goto error_out;
}
/* stat() the file so we know the size and can pre-allocate the right
* amount of memory. */
if (fstat(fd, &st) == -1) {
fprintf(stderr, _("cannot stat() configuration file %s\n"), filename);
-return NULL;
+goto error_out;
}
left = st.st_size;
data = malloc(st.st_size + 1);
if (data == NULL) {
fprintf(stderr, _("out of memory\n"));
-return NULL;
+goto error_out;
}
dest = data;
while (left != 0) {
@@ -77,9 +78,7 @@ read_config_file(const char *filename)
break;
if (res < 0) {
fprintf(stderr, _("read error\n"));
-close(fd);
-free(dest);
-return NULL;
+goto error_out;
}
dest += res;
left -= res;
@@ -87,6 +86,11 @@ read_config_file(const char *filename)
close(fd);
*dest = 0;
return data;
+
+error_out:
+if (fd != -1) close(fd);
+if (data) free(data);
+return NULL;
}
char *
diff --git a/ipa-client/ipa-getkeytab.c b/ipa-client/ipa-getkeytab.c
index 5a521d04127491193e971a00697f3e077796e01e..7218d7c54e527c0ecb92d0706c2310410e994036 100644
--- a/ipa-client/ipa-getkeytab.c
+++ b/ipa-client/ipa-getkeytab.c
@@ -89,7 +89,15 @@ static int ldap_sasl_interact(LDAP *ld, unsigned flags, void *priv_data, void *s
break;
}
- krb5_unparse_name(krbctx, princ, &outname);
+ krberr = krb5_unparse_name(krbctx, princ, &outname);
+
+ if (krberr) {
+fprintf(stderr, _("Unable to parse principal\n"));
+in->result = NULL;
+in->len = 0;
+ret = LDAP_LOCAL_ERROR;
+break;
+ }
in->result = outname;
in->len = strlen(outname);
--
1.7.6.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPS for the IPA LDAP server?
On 11/08/2011 08:43 AM, Rob Crittenden wrote: Stephen Gallagher wrote: On Mon, 2011-11-07 at 21:24 -0500, Adam Young wrote: I noticed that the PKI Directory server has a secure port set but the IPA DS instance does not: PKI nsslapd-secureport: 7390 Why doesn IPA set up ldapson port 636? I think you're confused. FreeIPA does indeed set up to listen on both 636 (LDAPS) and 389 (LDAP/TLS) by default. Take a look at 'netstat -lptn' as root. If you cannot connect to the LDAPS port, it may be due to a firewall issue or a certificate issue (make sure you have the FreeIPA CA cert loaded in /etc/openldap/cacerts and have called cacertdir_rehash on that directory) Adam, are you looking in dse.ldif? I'm guessing that the default settings aren't written. It does appear in ldap: Yes, I was. Thanks. $ ldapsearch -LL -x -D 'cn=directory manager' -W -s base -b cn=config nsslapd-secureport Enter LDAP Password: version: 1 dn: cn=config nsslapd-secureport: 636 It isn't set in dse.ldif: # grep -c nsslapd-secureport /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif 0 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 161 Make ipa-server-install clean after itself
How to test:
1) ipa-server-install -p secret123 -a secret123 --hostname
ipa.example.com
2) Continue in interactive wizard until IP address is requested (as
ipa.example.com cannot be resolved)
3) When it is entered and ipa-server-install gives this output:
# ipa-server-install -p kokos123 -a kokos123 --hostname ipa.example.com
--setup-dns
...
Please confirm the domain name [example.com]:
Unable to resolve IP address for host name
Please provide the IP address to be used for this host name: 10.16.78.93
Adding [10.16.78.93 ipa.example.com] to your /etc/hosts file <
...
hit CTRL+C to quit from the installation.
4) Try running ipa-server-install again. It will fail as /etc/hosts has
been changed - this patch fixes it.
>From fb3b36c7276ff7ecee6e0754a4399e6e635b044d Mon Sep 17 00:00:00 2001
From: Martin Kosek
Date: Tue, 8 Nov 2011 15:45:30 +0100
Subject: [PATCH] Make ipa-server-install clean after itself
ipa-server-install may create some files in the first phase of
installation before the actual installation and configuring of
services starts. If the installation is interrupted, these files
may prevent installing the server again until IPA server is
uninstalled. This may be confusing and annoying for the user.
This patch safely recovers all known files that could be created
in the first phase of the installation. No clean up is done if
the actual installation has not started yet or the installation
returned success.
https://fedorahosted.org/freeipa/ticket/1980
---
install/tools/ipa-server-install | 45 ++---
1 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index 1dbeef59620ff135efd68fb47fef740015b62639..9ac4bcb6e71d29cf33aadd93f6c632bfcafea041 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -66,6 +66,7 @@ from ipapython import services as ipaservices
pw_name = None
uninstalling = False
+installation_cleanup = True
VALID_SUBJECT_ATTRS = ['cn', 'st', 'o', 'ou', 'dnqualifier', 'c',
'serialnumber', 'l', 'title', 'sn', 'givenname',
@@ -547,6 +548,7 @@ def main():
global ds
global pw_name
global uninstalling
+global installation_cleanup
ds = None
safe_options, options = parse_options()
@@ -559,16 +561,19 @@ def main():
if options.uninstall:
uninstalling = True
+installation_cleanup = False
standard_logging_setup("/var/log/ipaserver-uninstall.log", options.debug)
else:
standard_logging_setup("/var/log/ipaserver-install.log", options.debug)
print "\nThe log file for this installation can be found in /var/log/ipaserver-install.log"
if not options.external_ca and not options.external_cert_file and is_ipa_configured():
+installation_cleanup = False
sys.exit("IPA server is already configured on this system.\n"
+ "If you want to reinstall the IPA server please uninstall it first.")
client_fstore = sysrestore.FileStore('/var/lib/ipa-client/sysrestore')
if client_fstore.has_files():
+installation_cleanup = False
sys.exit("IPA client is already configured on this system.\n"
+ "Please uninstall it first before configuring the IPA server.")
@@ -753,7 +758,17 @@ def main():
domain_name = domain_name.lower()
# Check we have a public IP that is associated with the hostname
-hostaddr = resolve_host(host_name)
+try:
+hostaddr = resolve_host(host_name)
+except HostnameLocalhost:
+print >> sys.stderr, "The hostname resolves to the localhost address (127.0.0.1/::1)"
+print >> sys.stderr, "Please change your /etc/hosts file so that the hostname"
+print >> sys.stderr, "resolves to the ip address of your network interface."
+print >> sys.stderr, "The KDC service does not listen on localhost"
+print >> sys.stderr, ""
+print >> sys.stderr, "Please fix your /etc/hosts file and restart the setup program"
+sys.exit(1)
+
if hostaddr is not None:
ip = CheckedIPAddress(hostaddr, match_local=True)
else:
@@ -858,6 +873,10 @@ def main():
dns_forwarders = ()
logging.debug("will use dns_forwarders: %s\n" % str(dns_forwarders))
+# Installation has started. No IPA sysrestore items are restored in case of
+# failure to enable root cause investigation
+installation_cleanup = False
+
# Create the management framework config file and finalize api
target_fname = '/etc/ipa/default.conf'
fd = open(target_fname, "w")
@@ -1136,18 +1155,18 @@ def main():
return 0
try:
+success = True
try:
-sys.exit(main())
+rval = main()
+if rval != 0:
+success = False
+sys.exit(rval)
except SystemExit, e:
+if e.code is not None or e.code != 0:
+
Re: [Freeipa-devel] LDAPS for the IPA LDAP server?
Stephen Gallagher wrote: On Mon, 2011-11-07 at 21:24 -0500, Adam Young wrote: I noticed that the PKI Directory server has a secure port set but the IPA DS instance does not: PKI nsslapd-secureport: 7390 Why doesn IPA set up ldapson port 636? I think you're confused. FreeIPA does indeed set up to listen on both 636 (LDAPS) and 389 (LDAP/TLS) by default. Take a look at 'netstat -lptn' as root. If you cannot connect to the LDAPS port, it may be due to a firewall issue or a certificate issue (make sure you have the FreeIPA CA cert loaded in /etc/openldap/cacerts and have called cacertdir_rehash on that directory) Adam, are you looking in dse.ldif? I'm guessing that the default settings aren't written. It does appear in ldap: $ ldapsearch -LL -x -D 'cn=directory manager' -W -s base -b cn=config nsslapd-secureport Enter LDAP Password: version: 1 dn: cn=config nsslapd-secureport: 636 It isn't set in dse.ldif: # grep -c nsslapd-secureport /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif 0 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPS for the IPA LDAP server?
On Mon, 2011-11-07 at 21:24 -0500, Adam Young wrote: > I noticed that the PKI Directory server has a secure port set but the > IPA DS instance does not: > > PKI > nsslapd-secureport: 7390 > > Why doesn IPA set up ldapson port 636? I think you're confused. FreeIPA does indeed set up to listen on both 636 (LDAPS) and 389 (LDAP/TLS) by default. Take a look at 'netstat -lptn' as root. If you cannot connect to the LDAPS port, it may be due to a firewall issue or a certificate issue (make sure you have the FreeIPA CA cert loaded in /etc/openldap/cacerts and have called cacertdir_rehash on that directory) signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPS for the IPA LDAP server?
Dne 8.11.2011 03:24, Adam Young napsal(a): I noticed that the PKI Directory server has a secure port set but the IPA DS instance does not: PKI nsslapd-secureport: 7390 Why doesn IPA set up ldaps on port 636? I guess secure connections are set up using STARTTLS. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
