[Freeipa-devel] [PATCH] more basic stuff for krbCanonicalName
Just like the krbPrincipalName attribute, we want to let the KDC read the krbCanonicalName, if it's set, and we want it to be unique as well. Nalin >From ff32dfe1f68a3ec20d247adbe042307eeb919e6b Mon Sep 17 00:00:00 2001 From: Nalin Dahyabhai Date: Thu, 4 Feb 2010 11:02:49 -0500 Subject: [PATCH 1/2] - allow the KDC to read krbCanonicalName --- install/share/default-aci.ldif |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index 9c058ae..3f74690 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -10,7 +10,7 @@ aci: (targetattr = "userPassword || krbPrincipalKey || sambaLMPassword || sambaN aci: (targetattr = "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory")(version 3.0; acl "Password change service can read/write passwords"; allow (read, write) userdn="ldap:///krbprincipalname=kadmin/chang...@$realm,cn=$REALM,cn=kerberos,$SUFFIX";;) aci: (targetattr = "userPassword || krbPrincipalKey || krbPasswordExpiration || sambaLMPassword || sambaNTPassword || passwordHistory")(version 3.0; acl "KDC System Account can access passwords"; allow (all) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";;) aci: (targetattr = "krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount")(version 3.0; acl "KDC System Account can update some fields"; allow (write) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";;) -aci: (targetattr = "krbPrincipalName || krbUPEnabled || krbMKey || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount")(version 3.0; acl "Only the KDC System Account has access to kerberos material"; allow (read, search, compare) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";;) +aci: (targetattr = "krbPrincipalName || krbCanonicalName || krbUPEnabled || krbMKey || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount")(version 3.0; acl "Only the KDC System Account has access to kerberos material"; allow (read, search, compare) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";;) aci: (targetfilter = "(|(objectClass=person)(objectClass=krbPrincipalAux)(objectClass=posixAccount)(objectClass=groupOfNames)(objectClass=posixGroup))")(targetattr != "aci || userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory")(version 3.0; acl "Account Admins can manage Users and Groups"; allow (add, delete, read, write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) aci: (targetfilter = "(objectClass=krbPwdPolicy)")(targetattr = "krbMaxPwdLife || krbMinPwdLife || krbPwdMinDiffChars || krbPwdMinLength || krbPwdHistoryLength")(version 3.0;acl "Admins can write password policies"; allow (read, search, compare, write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) aci: (targetattr = "givenName || sn || cn || displayName || title || initials || loginShell || gecos || homePhone || mobile || pager || facsimileTelephoneNumber || telephoneNumber || street || roomNumber || l || st || postalCode || manager || secretary || description || carLicense || labeledURI || inetUserHTTPURL || seeAlso || employeeType || businessCategory || ou")(version 3.0;acl "Self service";allow (write) userdn = "ldap:///self";;) @@ -35,7 +35,7 @@ aci: (targetfilter = "(objectClass=radiusprofile)")(targetattr != "aci || userPa dn: cn=services,cn=accounts,$SUFFIX changetype: modify add: aci -aci: (targetattr="krbPrincipalName || krbUPEnabled || krbPrincipalKey || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData")(version 3.0; acl "KDC System Account"; allow (read, search, compare, write) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";;) +aci: (targetattr="krbPrincipalName || krbCanonicalName || krbUPEnabled || krbPrincipalKey || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData")(version 3.0; acl "KDC System Account"; allow (read, search, compare, write) userdn="ldap:///uid=kdc,cn=sysaccounts,cn=etc,$SUFFIX";;) # Define which hosts can edit services dn: cn=services,cn=accounts,$SUFFIX -- 1.6.6.1 >From 6edabfa2ccc3ca9216108e301f553da83c9aa9ad Mon Sep 17 00:00:00 2001 From: Nalin Dahyabhai Date: Thu, 4 Feb 2010 11:07:48 -0500 Subject: [
[Freeipa-devel] [PATCH] jderose 039 Add support for the 'no_create', 'no_update', and 'no_search' Param flags
This feature will help restore some missing CLI functionality. It's
also a step toward making sure all our attribute metadata is plugable
with a per-attribute granularity.
See the new module docstring in ipalib/crud.py for details.
>From b8a67200ba1b2b7ce843dda7e3765bc921f03dcb Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Thu, 4 Feb 2010 09:52:33 -0700
Subject: [PATCH] Add support for the 'no_create', 'no_update', and 'no_search' Param flags
---
ipalib/crud.py | 112 ++-
tests/test_ipalib/test_crud.py |8 ++-
2 files changed, 114 insertions(+), 6 deletions(-)
diff --git a/ipalib/crud.py b/ipalib/crud.py
index 173fefc..77c97f3 100644
--- a/ipalib/crud.py
+++ b/ipalib/crud.py
@@ -16,14 +16,114 @@
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
"""
Base classes for standard CRUD operations.
+
+These base classes are for `Method` plugins that provide standard
+Create, Retrieve, Updated, and Delete operations (CRUD) for their corresponding
+`Object` plugin. In particuar, these base classes provide logic to
+automatically create the plugin args and options by inspecting the params on
+their corresponding `Object` plugin. This provides a single point of definition
+for LDAP attributes and enforces a simple, consistent API for CRUD operations.
+
+For example, say we want CRUD operations on a hypothetical "user" entry. First
+we need an `Object` plugin:
+
+>>> from ipalib import Object, Str
+>>> class user(Object):
+... takes_params = (
+... Str('login', primary_key=True),
+... Str('first'),
+... Str('last'),
+... Str('ipauniqueid', flags=['no_create', 'no_update']),
+... )
+...
+
+Next we need `Create`, `Retrieve`, `Updated`, and `Delete` plugins, and
+optionally a `Search` plugin. For brevity, we'll just define `Create` and
+`Retrieve` plugins:
+
+>>> from ipalib import crud
+>>> class user_add(crud.Create):
+... pass
+...
+>>> class user_show(crud.Retrieve):
+... pass
+...
+
+Now we'll register the plugins and finalize the `plugable.API` instance:
+
+>>> from ipalib import create_api
+>>> api = create_api()
+>>> api.register(user)
+>>> api.register(user_add)
+>>> api.register(user_show)
+>>> api.finalize()
+
+First, notice that our ``user`` `Object` has the params we defined with the
+``takes_params`` tuple:
+
+>>> list(api.Object.user.params)
+['login', 'first', 'last', 'ipauniqueid']
+>>> api.Object.user.params.login
+Str('login', primary_key=True)
+
+Although we defined neither ``takes_args`` nor ``takes_options`` for our
+``user_add`` plugin, the `Create` base class automatically generated them for
+us:
+
+>>> list(api.Command.user_add.args)
+['login']
+>>> list(api.Command.user_add.options)
+['first', 'last']
+
+Notice that ``'ipauniqueid'`` isn't included in the options for our ``user_add``
+plugin. This is because of the ``'no_create'`` flag we used when defining the
+``ipauniqueid`` param. Often times there are LDAP attributes that are
+automatically created by the server and therefor should not be supplied as an
+option to the `Create` plugin. Often these same attributes shouldn't be
+update-able either, in which case you can also supply the ``'no_update'`` flag,
+as we did with our ``ipauniqueid`` param. Lastly, you can also use the ``'no_search'`` flag for attributes that shouldn't be search-able (because, for
+example, the attribute isn't indexed).
+
+As with our ``user_add` plugin, we defined neither ``takes_args`` nor
+``takes_options`` for our ``user_show`` plugin; instead the `Retrieve` base
+class created them for us:
+
+>>> list(api.Command.user_show.args)
+['login']
+>>> list(api.Command.user_show.options)
+[]
+
+As you can see, `Retrieve` plugins take a single argument (the primary key) and
+no options. If needed, you can still specify options for your `Retrieve` plugin
+with a ``takes_options`` tuple.
+
+Flags like ``'no_create'`` remove LDAP attributes from those that can be
+supplied as *input* to a `Method`, but they don't effect the attributes that can
+be returned as *output*. Regardless of what flags have been used, the output
+entry (or list of entries) can contain all the attributes defined on the
+`Object` plugin (in our case, the above ``user.params``).
+
+For example, compare ``user.params`` with ``user_add.output_params`` and
+``user_show.output_params``:
+
+>>> list(api.Object.user.params)
+['login', 'first', 'last', 'ipauniqueid']
+>>> list(api.Command.user_add.output_params)
+['login', 'first', 'last', 'ipauniqueid']
+>>> list(api.Command.user_show.output_params)
+['login', 'first', 'last', 'ipauniqueid']
+
+Note that the above are all equal.
"""
+from frontend import Method, Object
import backend, frontend, parameters, output
-class Create(frontend.Method):
+class Create(Method
Re: [Freeipa-devel] [PATCH] 370 set default log level
John Dennis wrote: On 02/03/2010 04:27 PM, Rob Crittenden wrote: The ipa-*-manage programs had the default log level set to NOTSET which was causing copious logging to occur. Setting it to ERROR fixes this. ACK pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] add krbCanonicalName to the schema
Nalin Dahyabhai wrote: We'll need to incorporate this from krb5 1.7 as a prerequisite for maybe issuing server referrals at some point. Nalin ack, pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix condition bug in ipa-pwd-extop plugin. Variable used uninitialized. [Was: Re: Adding new IPA users on the CLI]
Pavel Zuna wrote: Rob Crittenden wrote: David O'Brien wrote: I tried this: # /usr/bin/ipa user-add --first=My --last=Name --password User login [mname]: password: Enter password again to verify: ipa: ERROR: Constraint violation:pre-hashed passwords are not valid I entered "password" as the password. If I enter nothing, it seems to create the user ok, but without a password (I think), so I don't know how to get a ticket. None of the shortened options (-f, -l, -p, etc.,) from v1.x work, either. This seems related to the changes we made for password migration. Pavel, can you take a look? It is easily reproduced. rob Programming mistake on my part. This should fix it. I also replaced all conditions, that assume LDAP_SUCCESS == 0. Please, add me to CC next time, otherwise I might take longer to notice. :) Pavel Ack, pushed to master. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] add krbCanonicalName to the schema
We'll need to incorporate this from krb5 1.7 as a prerequisite for maybe issuing server referrals at some point. Nalin >From d0faa0e87ea1f4c211d29f78dc95e7953eaabee6 Mon Sep 17 00:00:00 2001 From: Nalin Dahyabhai Date: Thu, 4 Feb 2010 10:46:43 -0500 Subject: [PATCH 1/1] - pull in updated schema which adds the krbCanonicalName attribute --- install/share/60kerberos.ldif | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/install/share/60kerberos.ldif b/install/share/60kerberos.ldif index 3431d22..edfdb57 100644 --- a/install/share/60kerberos.ldif +++ b/install/share/60kerberos.ldif @@ -21,12 +21,26 @@ dn: cn=schema #specific syntax definitions # Kerberos Object Class(6) class# version# #specific class definitions +# +#iso(1) +# member-body(2) +#United States(840) +# mit (113554) +#infosys(1) +# ldap(4) +#attributeTypes(1) +# Kerberos(6) #Attribute Type Definitions # # This is the principal name in the RFC 1964 specified format attributetypes: ( 2.16.840.1.113719.1.301.4.1.1 NAME 'krbPrincipalName' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) +# If there are multiple krbPrincipalName values for an entry, this +# is the canonical principal name in the RFC 1964 specified +# format. (If this attribute does not exist, then all +# krbPrincipalName values are treated as canonical.) +attributetypes: ( 1.2.840.113554.1.4.1.6.1 NAME 'krbCanonicalName' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) # This specifies the type of the principal, the types could be any of # the types mentioned in section 6.2 of RFC 4120 attributetypes: ( 2.16.840.1.113719.1.301.4.3.1 NAME 'krbPrincipalType' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) @@ -262,7 +276,7 @@ objectClasses: ( 2.16.840.1.113719.1.301.6.4.1 NAME 'krbKdcService' SUP ( krbSer objectClasses: ( 2.16.840.1.113719.1.301.6.5.1 NAME 'krbPwdService' SUP ( krbService ) ) ## The principal data auxiliary class. Holds principal information ## and is used to store principal information for Person, Service objects. -objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData ) ) +objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData ) ) ## This class is used to create additional principals and stand alone principals. objectClasses: ( 2.16.840.1.113719.1.301.6.9.1 NAME 'krbPrincipal' SUP ( top ) MUST ( krbPrincipalName ) MAY ( krbObjectReferences ) ) ## The principal references auxiliary class. Holds all principals referred -- 1.6.6.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Implementing --all as a global option
On Thu, 2010-02-04 at 15:55 +0100, Pavel Zuna wrote:
> Pavel Zuna wrote:
> > I've run into a little problem when implementing --all as a global
> > option. The problem is that I can't see a way, to propagate it to the
> > server side. Plugins could always retrieve all attributes and the client
> > would choose what to display, but that would be very ineffective
> > (especially when executing *-find commands).
> >
> > Either we add a way to pass additional information over XML-RPC (command
> > independent flags) or we go back to non-global --all options.
> >
> > Thoughts?
> >
> > Pavel
> >
>
> Hey Jason,
> we talked about this a bit on Tuesday meeting and you mentioned having some
> plans about extending the information being transmitted over XML-RPC. I
> remember
> something about "extras" and "cookies", but that's pretty much it. If you
> could
> just summarize what you had in mind, I'll start figuring stuff out and
> implementing it.
>
> Pavel
>
Sure. XML-RPC arguments are supplied in a single params list (this is
the XML-RPC spec, not an IPA specific thing). Right now our calling
signature is:
[arg1, arg2, ..., argN, ]
We make an educated guess as to whether the last argument is in fact an
options dict based on its type. This works for now as the parameter
system doesn't yet support compound dict values (it only supports
compound list values, which you create using multivalue=True). I'm sure
it's only a matter of time till we need compound dict values, so we
really need to change the XML-RPC signature before we release v2 and
become obligated to stay backward compatible.
I propose we change the signature to:
[args, options, extra]
Where:
`args` is a list of arguments for the command (can be empty)
`options` is a dict of options for the command (can be empty)
`extra` is a dict of extensible special variables (can be empty)
We really need the `extra` dict because a lot of XML-RPC libraries don't
make it especially easy (if even possible) to set HTTP headers (the
Python implementation included). So my main use case for `extra` is to
pass things like cookies and the locale when they can't be supplied in
the HTTP headers. Global options like --all are also a great use case
for `extra`, and I'm sure we'll have more down the road. If something
like the locale is present in both the HTTP headers and in `extra`, the
value in `extra` should take precedence.
We should allow `extra`, `options`, and `args` to be missing in the call
so that all of these would be valid calls:
[] # Implies [[], {}, {}]
[['foo']] # Implies [['foo'], {}, {}]
[[], {'foo': 'bar'}] # Implies [[], {'foo': 'bar'}, {}]
[[], {}, {'foo': 'bar'}]
Make sense? Does anyone disagree with this approach, have suggestions?
The JSON-RPC call signature is already [args, options]... and I'll
change this to [args, options, extra] shorty after the alpha release.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Fix condition bug in ipa-pwd-extop plugin. Variable used uninitialized. [Was: Re: Adding new IPA users on the CLI]
Rob Crittenden wrote: David O'Brien wrote: I tried this: # /usr/bin/ipa user-add --first=My --last=Name --password User login [mname]: password: Enter password again to verify: ipa: ERROR: Constraint violation:pre-hashed passwords are not valid I entered "password" as the password. If I enter nothing, it seems to create the user ok, but without a password (I think), so I don't know how to get a ticket. None of the shortened options (-f, -l, -p, etc.,) from v1.x work, either. This seems related to the changes we made for password migration. Pavel, can you take a look? It is easily reproduced. rob Programming mistake on my part. This should fix it. I also replaced all conditions, that assume LDAP_SUCCESS == 0. Please, add me to CC next time, otherwise I might take longer to notice. :) Pavel 0001-Fix-condition-bug-in-ipa-pwd-extop-plugin.-Variable-.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Implementing --all as a global option
Pavel Zuna wrote: I've run into a little problem when implementing --all as a global option. The problem is that I can't see a way, to propagate it to the server side. Plugins could always retrieve all attributes and the client would choose what to display, but that would be very ineffective (especially when executing *-find commands). Either we add a way to pass additional information over XML-RPC (command independent flags) or we go back to non-global --all options. Thoughts? Pavel Hey Jason, we talked about this a bit on Tuesday meeting and you mentioned having some plans about extending the information being transmitted over XML-RPC. I remember something about "extras" and "cookies", but that's pretty much it. If you could just summarize what you had in mind, I'll start figuring stuff out and implementing it. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
