Re: [Freeipa-devel] Failed push to github

2013-03-08 Thread Petr Viktorin 

On 03/08/2013 12:38 AM, Nathaniel McCallum wrote:

I tried to push my branch of FreeIPA to github and it failed with the
following message. I don't know if anything can be done to fix it, but I
figured I'd mention it.

error: object 0b36ce6dcbfc8d7e6cda632e06a09c369428a2db:invalid
author/committer line - bad date
fatal: Error in object
error: pack-objects died of signal 13
error: failed to push some refs to
'g...@github.com:npmccallum/freeipa.git'

Nathaniel



Yes, we have some commits with invalid commit times.
If you fork https://github.com/encukou/freeipa you should be fine.
(I've asked Github staff to turn off the checks so I could push it 
initially.)


--
Petr³

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

Re: [Freeipa-devel] [PATCH] 376-377 Use tkey-gssapi-keytab in named.conf

2013-03-08 Thread Petr Spacek 

On 8.3.2013 00:14, Rob Crittenden wrote:

Martin Kosek wrote:

Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential
and tkey-domain and replace them with tkey-gssapi-keytab which avoids
unnecessary Kerberos checks on BIND startup and can cause issues when
KDC is not available.

Both new and current IPA installations are updated.

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



Still reviewing this but I noticed that after upgrading my 3.1.99 server
pre-patch to with with-patch version the connections argument in named.conf
got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4
during the initial install too?


For 3.2 it doesn't matter. Anything = 2 should be okay, but more connections 
should not harm.


Higher value should allow higher level of parallelism, it is one of tuning 
parameters. Value 4 was necessary to prevent deadlocks in some previous 
versions of bind-dyndb-ldap.


--
Petr^2 Spacek

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

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Sumit Bose 
On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote:
 Based on a comment from Sumit in ticket
 https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline
 of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags
 
 There is a bit of hand waving going on around how the flags are
 actually set inside the KDB plugin since I'm not at all familiar
 with that code but I don't expect it to be too big a deal.
 
 I'm not necessarily volunteering to do this work, just trying to
 keep the ball moving forward.

Thank you for setting up the design page. I would like to suggest that
we should try to include all currently available flags in one run,
because:
- some flags related to OTP would be needed as well
- it is only a minor increase the development effort
- it is only a minor increase in the QE effort. Instead of doing
  * set/unset flag in CLI/WebUI
  * check with kdamin.local if the flag is in the expected state
  for a single attribute it has to be done for a list of attributes
  (maybe the steps can be added to a new 'How to test' section on the
  design page)
- it will help to find a good solution how to handle the flags in the
  CLI/WebUI

I think the last point is important because the flags are needed for all
Kerberos principals, i.e. users, hosts and services. Instead of adding a
list of new options/check boxes to each of the CLI commands/WebUI pages
it might be more helpful to handle the flags separately. The CLI can get
a new command class, e.g. krbflags. In the WebUI the Kerberos flags can be
shown and modified in a separate tab, I hope this will allow to use a
common template to users, hosts and services. These are only rough ideas
and suggestions, my point is that if we not only add a single flag but
about 15 it might be easier to find a good and usable interface to
modify them.

bye,
Sumit

 
 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

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Jan Cholasta 

Hi,

On 7.3.2013 21:15, Rob Crittenden wrote:

Based on a comment from Sumit in ticket
https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of
how one might do it: http://freeipa.org/page/V3/Kerberos_Flags


Can we have one multi-valued attribute which contains names of flags to 
set instead of one attribute per flag? It might make adding new flags 
easier.


Would it make sense to add a global configuration option to turn flags 
on or off for all services of a given type?




There is a bit of hand waving going on around how the flags are actually
set inside the KDB plugin since I'm not at all familiar with that code
but I don't expect it to be too big a deal.

I'm not necessarily volunteering to do this work, just trying to keep
the ball moving forward.

rob



Honza

--
Jan Cholasta

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

Re: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type

2013-03-08 Thread Martin Kosek 

On 03/07/2013 06:32 PM, Sumit Bose wrote:

On Wed, Mar 06, 2013 at 05:33:43PM +0100, Sumit Bose wrote:

On Wed, Mar 06, 2013 at 08:51:47AM -0500, Simo Sorce wrote:

On Wed, 2013-03-06 at 14:49 +0100, Martin Kosek wrote:

On 03/06/2013 10:41 AM, Sumit Bose wrote:

On Tue, Mar 05, 2013 at 05:13:58PM +0100, Martin Kosek wrote:

On 03/04/2013 04:22 PM, Sumit Bose wrote:

On Fri, Mar 01, 2013 at 08:58:34AM -0500, Simo Sorce wrote:

On Fri, 2013-03-01 at 10:08 +0100, Martin Kosek wrote:

On 03/01/2013 09:20 AM, Sumit Bose wrote:

On Fri, Mar 01, 2013 at 08:33:51AM +0100, Martin Kosek wrote:

On 02/28/2013 03:28 PM, Simo Sorce wrote:

On Thu, 2013-02-28 at 13:02 +0100, Martin Kosek wrote:

On 02/28/2013 12:42 PM, Sumit Bose wrote:

On Thu, Feb 28, 2013 at 08:44:35AM +0100, Martin Kosek wrote:

On 02/27/2013 06:48 PM, Sumit Bose wrote:



Hi Sumit,

This looks like a good idea and would prevent the magic default PAC type, yes.
Though I would not add this service-specific setting to global IPA config 
object.

I would rather like to see that in the service tree, for example as a
configuration option of the service root which could be controlled with
serviceconfig-* commands (we already have dnsconfig, trustconfig), e.g:

# ipa serviceconfig-add-pacmap --service=nfs --pac-type=NONE
# ipa serviceconfig-add-pacmap --service=cifs --pac-type=PAD
# ipa serviceconfig-show
   Default PAC Map: nfs:NONE, cifs:PAD


Are you thinking of having this in addition to the for-all-services
default values in cn=ipaConfig,cn=etc or shall those be dropped? I don't
like the first case because then three different objects needs to be
consulted to find out which is the right type. This wouldn't be an issue
for the plugin, but I think it is hard for the user/admin to follow.


Hm, you are right.



If the current defaults shall be dropped I think this is a major change
because it will require changes in the current CLI and WebUI which will
be visible to the users. I'm not against this change, I'm just wondering
if it is worth the effort for the next release?

Maybe an argument to keep this is in global default is that the settings
are used for the host/*.* services as well which are in a different
sub-tree of the cn=accounts container. Additionally in future we might
want apply those setting to the user TGTs as well?


Yeah, that was actually my point. That we are mixing service-specific PAC
rules to the global setting. Which may be shared with host/*.* principals and
user principals. This automatic PAC rules may require some designing so that is
is generally usable.


I think putting everything in the general config is more understandable
and discoverable. These per-service defaults are basically exceptions to
the general rule so it make sense to keep everything together.

Simo.



Ok, if these are really just an exceptions to the general rule (and there will
not be too many of them), I think we can leave it in config entry. But if we
expect to have exceptions for other types of entries (hosts, users), I think we
should rather use something like service:nfs:NONE do distinguish this 
exception.

Question is, do we want to implement the interface and processing for that in
current Sumit's patches or do we use that is they are?


I would like to update the patches so that they can handle the
service:TYPE style entry and replace the current update code with just
adding nfs:NONE to the global options. I will update the design page
accordingly, too.


Ok. If the update procedure shrinks just to adding service:nfs:NONE then it'd
be great.


If we need to distinguish between service principals and user principals
I would prefer rather use a special keyword for upns

service: is redundant and I do not want here to be able to say
upn:martin:NONE because per principal options are available on the
principal object.

I actually really do not see the need for changing the default just for
user principals. If we are worried that one day we might want to really
have upn:NONE, then let's use nfs/:NONE, host/:NONE etc... so one day we
might add upn:NONE and the lack of / will tell us this is not a service
named upn/foo.bar.baz but rather it means user principal names.

However I do not see us ever really needing upn:NONE


I would prefer if the enhancements needed for the CLI and WebUI can be
covered by other/new tickets, but I'm happy to add the needed
information to the design page too.

bye,
Sumit


I am OK with adding the interface for this special exception later. In that
case, a ticket + note in the design as you mentioned would be enough.


Ack.

Simo.



Please find attached a new version of the patches. 0095 i(updating) is
renamed and much simpler now. I opened
https://fedorahosted.org/freeipa/ticket/3484 to added the needed change
for 'service:TYPE' to CLI and WebUI. For the time being I've added
patch 0108 which simply allows 'nfs:NONE' as a type to make sure that it
is not deleted accidentally when e.g. using the WebUI. If you do not
like it

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Sumit Bose 
On Fri, Mar 08, 2013 at 10:31:58AM +0100, Jan Cholasta wrote:
 Hi,
 
 On 7.3.2013 21:15, Rob Crittenden wrote:
 Based on a comment from Sumit in ticket
 https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of
 how one might do it: http://freeipa.org/page/V3/Kerberos_Flags
 
 Can we have one multi-valued attribute which contains names of flags
 to set instead of one attribute per flag? It might make adding new
 flags easier.

Yes, as said I think it makes sense to just add support for all flags to
find a good/scalable design. This way it would be a bit harder for
external applications which access the LDAP server directly to see which
flags are supported, but it will keep the schema much cleaner.

 
 Would it make sense to add a global configuration option to turn
 flags on or off for all services of a given type?

In general yes, I'm just wondering if this should be handled here or
tracked by a separate ticket/design because different LDAP objects will
be used to manage the defaults. Additionally we might want to think a
bit longer about how global defaults and individual flags will be
merged. I think it is not as easy as with the authorization date (PAC
type) where we said that individual setting replaces the defaults
because iirc the REQUIRES_PRE_AUTH is currently always set. Please note
also that tis is not only about services but hosts and users as well.

bye,
Sumit

 
 
 There is a bit of hand waving going on around how the flags are actually
 set inside the KDB plugin since I'm not at all familiar with that code
 but I don't expect it to be too big a deal.
 
 I'm not necessarily volunteering to do this work, just trying to keep
 the ball moving forward.
 
 rob
 
 
 Honza
 
 -- 
 Jan Cholasta
 
 ___
 Freeipa-devel mailing list
 Freeipa-devel@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-devel

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

Re: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges

2013-03-08 Thread Martin Kosek 

On 03/05/2013 12:59 PM, Tomas Babej wrote:

Hi,

Any of the following checks:
   - overlap between primary RID range and secondary RID range
   - overlap between secondary RID range and secondary RID range

is performed now only if both of the ranges involved are local
domain ranges.

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



I think the patch is functionally OK (I tested it), I would just change the 
flow of the following:


@@ -194,19 +198,22 @@ static int ranges_overlap(struct range_info *r1, struct 
range_info *r2)

 r1-id_range_size, r2-id_range_size))
 return 2;

-/* check if secondary rid range overlaps with existing secondary rid 
range */

+/**
+ * The following 3 checks are relevant only if both ranges are local.
+ * Check if secondary rid range overlaps with existing secondary rid
+ * range. **/
 if (intervals_overlap(r1-secondary_base_rid, r2-secondary_base_rid,
-r1-id_range_size, r2-id_range_size))
+r1-id_range_size, r2-id_range_size)  local_ranges)
 return 3;
...


TO something like

...
/**
 * The following checks are relevant only if both ranges are local.
 * Check if secondary rid range overlaps with existing secondary rid
 * range. **/
if (local_ranges) {
... do the checks
}
...

Doing it your way, intervals_overlap() function is called 3 times when not 
needed + it is not so obvious that these checks are only done with 
local_ranges only.


Martin

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

[Freeipa-devel] [PATCH] 383 Use new 389-ds-base cleartext password API

2013-03-08 Thread Martin Kosek 

The way how unhashed password is stored in the entry was changed in
389-ds-base-1.3.0, it is now stored in an entry extension rather than
in a magic attribute unhashed#user#password. New API using an entry
extension was introduced. ipa-pwd-extop should take advantage of the
new API as the old one will be removed in 389-ds-base-1.3.1.

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

---
This patch is based on Noriko's candidate patch in 389-ds-base ticket. I tested 
various password scenarios including migration of users with cleartext/hashed 
passwords, everything worked OK.


Martin
From 57bdfba0fd46d2d21ac8dc13d7723a23de3712b3 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Fri, 8 Mar 2013 13:01:45 +0100
Subject: [PATCH] Use new 389-ds-base cleartext password API

The way how unhashed password is stored in the entry was changed in
389-ds-base-1.3.0, it is now stored in an entry extension rather than
in a magic attribute unhashed#user#password. New API using an entry
extension was introduced. ipa-pwd-extop should take advantage of the
new API as the old one will be removed in 389-ds-base-1.3.1.

https://fedorahosted.org/freeipa/ticket/3439
---
 .../ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
index 3b512a4744d3edddc52e224c11aaa93388d06b75..0318cecdcc37690838ffc778817cd60c9a8376a0 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
@@ -211,13 +211,19 @@ static int ipapwd_pre_add(Slapi_PBlock *pb)
 slapi_ch_free_string(userpw);
 userpw = tmp;
 } else if (slapi_is_encoded(userpw)) {
-/* check if we have access to the unhashed user password */
-char *userpw_clear =
-slapi_entry_attr_get_charptr(e, unhashed#user#password);
+const char *userpw_clear = NULL;
+Slapi_Value **pwvals = NULL;
 
-/* unhashed#user#password doesn't always contain the clear text
- * password, therefore we need to check if its value isn't the same
- * as userPassword to make sure */
+/* Try to get clear password from an entry extension.
+ * This function does not return a copy of the values,
+ * no need to free them. */
+rc = slapi_pw_get_entry_ext(e, pwvals);
+if (LDAP_SUCCESS == rc) {
+userpw_clear = slapi_value_get_string(pwvals[0]);
+}
+
+/* Fail if we did not get a real clear text password from
+ * the extension. This will happen if the password is hashed. */
 if (!userpw_clear || (0 == strcmp(userpw, userpw_clear))) {
 rc = LDAP_CONSTRAINT_VIOLATION;
 slapi_ch_free_string(userpw);
@@ -225,8 +231,6 @@ static int ipapwd_pre_add(Slapi_PBlock *pb)
 userpw = slapi_ch_strdup(userpw_clear);
 }
 
-slapi_ch_free_string(userpw_clear);
-
 if (rc != LDAP_SUCCESS) {
 /* we don't have access to the clear text password;
  * let it slide if migration is enabled, but don't
-- 
1.8.1.4

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

Re: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master

2013-03-08 Thread Petr Viktorin 

On 03/07/2013 08:27 PM, Rob Crittenden wrote:

Petr Viktorin wrote:

On 03/06/2013 09:52 PM, Rob Crittenden wrote:

Petr Viktorin wrote:

[...]

On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config is added before the entry
itself.
I didn't test everything as I didn't get the access.


It shouldn't make a difference. What isn't working?


I get a CRITICAL message in the log:

add aci:
 (targetattr=dnaNextRange || dnaNextValue ||
dnaMaxValue)(version 3.0;acl permission:Modify DNA Range;allow (write)
groupdn = ldap:///cn=Modify DNA
Range,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;)


modifying entry cn=Posix IDs,cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config

2013-03-07T11:01:48Z DEBUG stderr=ldap_initialize(
ldap://vm-081.idm.lab.eng.brq.redhat.com:389/??base )
ldap_modify: No such object (32)

2013-03-07T11:01:48Z CRITICAL Failed to load replica-acis.ldif: Command
'/usr/bin/ldapmodify -v -f /tmp/tmpT55upM -H
ldap://vm-081.idm.lab.eng.brq.redhat.com:389 -x -D cn=Directory Manager
-y /tmp/tmplFeere' returned non-zero exit status 32



Gotcha. I moved where the replica acis are loaded.


Please attach the patch :)

[...]

+failed = 0
+for ent in entries:



This loops more than necessary and is somewhat hard to follow. Consider
using for-else here:

for ...:
 ...
 if okay:
 break
else:
 raise error


I simplified things a bit but a for/else won't work here as we need to
check all ranges all the time. It is perfectly fine to not fit into a
range, as long as it fits into SOME range.


Well, that's how for's (not if's) else clause works -- it's executed
after all the looping's done if you didn't `break` out.
http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops


Maybe I'm just used to it and it's too esoteric to the average reader,
though.


Thanks for the vote of confidence. Like I said, I wanted it to check all
the ranges. A for/else quits on the break, which I guess is really
probably ok assuming we trust that nothing else is going to stuff bad
ranges in. I can go ahead and make the change.


Your code also breaks out as soon as a good range is found.
Anyway this is a small nitpick; the loop works fine as it is.


[...]

Ok, I'll drop this since it doesn't affect things with the new LDAP
backend.


Please do, you left it in by mistake.


Yeah, there it is sitting unsquashed in my tree :-(



I also added one change related to the LDAP core changes. In the past if
you did not have a ticket it would prompt for DM password. This was
broken after the updates. I added an additional except in
test_connection().


This should also be fixed soon in ipaldap. Thanks for putting up with
the changes.



So should I drop this in my patch then? I don't really like having to
import ldap.


You can if you're fine with waiting until my patches are pushed.
Otherwise it's covered by https://fedorahosted.org/freeipa/ticket/3499

--
Petr³

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

Re: [Freeipa-devel] [PATCHES] 116-119 Make LDAP schema retrieval optional

2013-03-08 Thread Petr Viktorin 

On 03/07/2013 06:21 PM, Jan Cholasta wrote:

On 7.3.2013 17:59, Petr Viktorin wrote:

On 03/07/2013 04:33 PM, Jan Cholasta wrote:

On 7.3.2013 14:53, Petr Viktorin wrote:

On 03/07/2013 01:43 PM, Jan Cholasta wrote:

Hi,

these patches add flags to LDAPClient and IPAdmin constructors which
can
be used to disable schema retrieval and decoding of attributes. This
should make interacting with AD easier (see
http://www.redhat.com/archives/freeipa-devel/2013-March/msg00076.html).




Honza

[...]


Updated patches attached.

Honza



In LDAPEntry.__setitem__, schema.get_obj is used without checking if the
schema is None.



I knew I forgot something! Thanks. Fixed.

Updated patches attached.

Honza



ACK

--
Petr³

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

[Freeipa-devel] [RFE] Multiple trust servers per realm

2013-03-08 Thread Alexander Bokovoy 

Hi,

http://www.freeipa.org/page/V3/MultipleTrustServers covers RFE to have
multiple domain controllers exposed to trusted domains.

Attached patch also implements needed changes for ipa-adtrust-install
part. Global trust configuration options are already implemented and
available in git master, while Web UI support for them needs to be
added.

The patch attached actually fixes our current (rather wrong) way of
exposing all LDAP- and Kerberos-related SRV records to default site
configuration and _msdcs SRV namespace. This was wrong because it
assumed that all servers mentioned in SRV records could be domain
controllers, that is, they are usable to contact over SMB protocol.
The latter isn't true until we ran ipa-adtrust-install on them.

The patch only exposes those servers which manage cifs/fqdn@REALM
services and only if those services are also members of cn=adtrust
agents container. This is fairly strict filter and it allows also to
have other types of SMB servers as part of the realm.

Below is a copy of the RFE:
==
__NOTOC__

= Overview =

Ticket [https://fedorahosted.org/freeipa/ticket/2189 #2189];

Each FreeIPA server in the realm has potential to serve as domain
controller in the cross-forest realm trust. This page outlines design
for implementing multiple servers support in FreeIPA.

= Use Cases =

Once ttipa-adtrust-install/tt ran on the FreeIPA server, the server
can handle requests from trusted domains by means of Samba project's
ttsmbd/tt and ttwinbindd/tt daemons.

Hosts in FreeIPA realm may be enrolled against specific FreeIPA replica
server. User from trusted domain can access these hosts and their
identities will be resolved against the replica. However, if replica
server does not have trust support configured, these identities will not
be processed since running ttwinbindd/tt process is required to
contact the trusted domain's domain controllers and Global Catalog
servers.

Domain controllers are advertised to clients via SRV records in DNS.
Since replica servers may be arranged in a specific topology, adding new
domain controller would need to respect the topology design. It means
priority/weight of the domain controller compared to other domain
controllers should be adjustable. Prime use case for this is branch
office deployments.

= Design= 


* Each domain controller uses separate identity and service key to talk
  to FreeIPA LDAP server. The identity is tied to the server hostname.

* Service principal is ttcifs/hostname@REALM/tt, identified in LDAP
  as ttkrbprincipalname=cifs/hostname@REALM/tt.

* All identities are members of ttcn=adtrust
  agents/tt,ttcn=sysaccounts/tt,ttcn=etc/tt,tt$SUFFIX/tt.
  Thus, all replica servers can see what other servers are providing
  domain controller service.

* Replica server only becomes domain controller when
  ttipa-adtrust-install/tt utility was executed on it. It means all
  DC setup is delivered via the ttipa-adtrust-install/tt.

* ttipa-adtrust-install/tt should be able to detect other DCs by
  looking at existing identities as members of the ttcn=adtrust
  agents/tt,ttcn=sysaccounts/tt,ttcn=etc/tt,tt$SUFFIX/tt
  tree and modify list of SRV records under tt_msdcs/tt and default
  site configuration if DNS is controlled by FreeIPA.

* Domain Controller priority/weight can be modified at run time since it
  only affects SRV records in the DNS (if FreeIPA controls the DNS).
  Normal ttipa dnsrecord-mod/tt commands should be used for this
  purpose, operating on SRV records for tt_msdcs/tt and default site
  configuration.

* There are trust properties that are global for the realm. Some of them
  are modifiable, some not. Thus, ttipa trustconfig-show/tt and
  ttipa trustconfig-mod/tt should reflect both global and local
  settings (realm-wise and DC-wise).

* Following properties of the trust are global for the realm:
** NetBIOS domain name (read-only, affects existing trusts)
** Domain name (read-only, affects existing trusts)
** Domain GUID (read-only, informational)
** Additional domain suffixes exposed to the trusted party, handled as
   black list against global list of additional domains associated with our
   or transitive realm, read/write
** Fallback primary group (read-write)

* Following properties of the trust are per Domain Controller:
** priority of the DC and GC services (read-write, DNS SRV record)

Details on ttipa trustconfig/tt commands design are available at
http://www.freeipa.org/page/V3/Trust_config_command
Details on additional domain suffixes handling are available at
http://www.freeipa.org/page/V3/Domain_suffixes

= Implementation =
Implementation-wise there are three parts:

* ttipa-adtrust-install/tt:
** Gather list of CIFS services that are also members of ttcn=adtrust
   agents/tt and add SRV records for them to _msdcs in
   
ipaserver/install/adtrustinstance.py:ADTrustInstance::__add_dns_service_records().
** Once Global Catalog Server

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Simo Sorce 
On Thu, 2013-03-07 at 15:15 -0500, Rob Crittenden wrote:
 Based on a comment from Sumit in ticket 
 https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of 
 how one might do it: http://freeipa.org/page/V3/Kerberos_Flags
 
 There is a bit of hand waving going on around how the flags are actually 
 set inside the KDB plugin since I'm not at all familiar with that code 
 but I don't expect it to be too big a deal.
 
 I'm not necessarily volunteering to do this work, just trying to keep 
 the ball moving forward.

How is upgrade performed ?

What happens during upgrade when mixed old/new servers are around ?

Please add explicitly the process in the Design page, this is crucial to
decide if this design is acceptable or not.

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] [PATCHES] 116-119 Make LDAP schema retrieval optional

2013-03-08 Thread Martin Kosek 

On 03/08/2013 02:13 PM, Petr Viktorin wrote:

On 03/07/2013 06:21 PM, Jan Cholasta wrote:

On 7.3.2013 17:59, Petr Viktorin wrote:

On 03/07/2013 04:33 PM, Jan Cholasta wrote:

On 7.3.2013 14:53, Petr Viktorin wrote:

On 03/07/2013 01:43 PM, Jan Cholasta wrote:

Hi,

these patches add flags to LDAPClient and IPAdmin constructors which
can
be used to disable schema retrieval and decoding of attributes. This
should make interacting with AD easier (see
http://www.redhat.com/archives/freeipa-devel/2013-March/msg00076.html).




Honza

[...]


Updated patches attached.

Honza



In LDAPEntry.__setitem__, schema.get_obj is used without checking if the
schema is None.



I knew I forgot something! Thanks. Fixed.

Updated patches attached.

Honza



ACK



Pushed to master.

Martin

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

Re: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab

2013-03-08 Thread Tomas Babej 

On Thu 07 Mar 2013 11:01:33 PM CET, Rob Crittenden wrote:

Petr Viktorin wrote:

On 03/07/2013 04:27 PM, Tomas Babej wrote:

On 03/07/2013 04:12 PM, Petr Viktorin wrote:

Thanks! I just have two more very minor nitpicks.

On 03/06/2013 01:04 PM, Tomas Babej wrote:

On 03/05/2013 02:10 PM, Petr Viktorin wrote:

Thanks! The mechanism works, but see below.

This is a RFE so it needs a design document.


http://freeipa.org/page/V3/Client_install_using_keytab


Please also add the link to the commit message.


I think you answered Petr²'s security questions adequately.
Petr, note that this is a client-side change; if the keytab is
compromised the attacker can do all this manually anyway.


diff --git a/ipa-client/ipa-install/ipa-client-install
b/ipa-client/ipa-install/ipa-client-install
index
308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b


100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -104,6 +104,8 @@ def parse_options():

[...]

@@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore):
  except ipaclient.ntpconf.NTPConfigurationError:
  pass

-if options.unattended and (options.password is None and
options.principal is None and options.prompt_password is False) and
not options.on_master:
-root_logger.error(One of password and principal are
required.)
+if options.unattended and ((options.password is None and
+options.principal is None and
+options.keytab is None and
+options.prompt_password is False)\
+and not options.on_master):


Please also remove the inner parentheses and the backslash.


Both fixed, updated patch attached.

Tomas


ACK, thanks!



This needs related man page updates before we can push it.



Man pages updated:

[tbabej@thinkpad7 freeipa]$ git diff
diff --git a/ipa-client/man/ipa-client-install.1 
b/ipa-client/man/ipa-client-ins

[...]
+\fB\-k\fR, \fB\-\-keytab\fR
+Path to backed up host keytab from previous enrollment.
+.TP
[...]
diff --git a/ipa-client/man/ipa-join.1 b/ipa-client/man/ipa-join.1
[...]
+\fB\-f,\-\-force\fR
+Force enrolling the host even if host entry exists.
+.TP


Can you update the design to specifically include that the old
certificate needs to be revoked, not just that a new certificate be
issued (sort of implied, and it worked in my testing)?


I updated the design page accordingly. However, shouldn't be this 
handled by server side automatically?



rob


Updated patch attached.
From 73f533075321520fb94218641e1d45533cdfa9f3 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 26 Feb 2013 13:20:13 +0100
Subject: [PATCH] Add support for re-enrolling hosts using keytab

A host that has been recreated  and does not have its
host entry disabled or removed, can be re-enrolled using
a previously backed up keytab file.

A new option --keytab has been added to ipa-client-install. This
can be used to specify path to the keytab and can be used instead
of -p or -w options.

A new option -f has been added to ipa-join. It forces client to
join even if the host entry already exits. A new certificate,
ssh keys are generated, ipaUniqueID stays the same.

Design page: http://freeipa.org/page/V3/Client_install_using_keytab

https://fedorahosted.org/freeipa/ticket/3374
---
 ipa-client/ipa-install/ipa-client-install | 40 +++
 ipa-client/ipa-join.c | 14 +++
 ipa-client/man/ipa-client-install.1   |  3 +++
 ipa-client/man/ipa-join.1 |  3 +++
 4 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..bd458ed09856dfccd161b1dc96f4b1e0ec7f7e40 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -104,6 +104,8 @@ def parse_options():
   help=principal to use to join the IPA realm),
 basic_group.add_option(-w, --password, dest=password, sensitive=True,
   help=password to join the IPA realm (assumes bulk password unless principal is also set)),
+basic_group.add_option(-k, --keytab, dest=keytab,
+  help=path to backed up keytab from previous enrollment),
 basic_group.add_option(-W, dest=prompt_password, action=store_true,
   default=False,
   help=Prompt for a password to join the IPA realm),
@@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore):
 except ipaclient.ntpconf.NTPConfigurationError:
 pass
 
-if options.unattended and (options.password is None and options.principal is None and options.prompt_password is False) and not options.on_master:
-root_logger.error(One of password and

Re: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges

2013-03-08 Thread Tomas Babej 

On 03/07/2013 11:48 PM, Rob Crittenden wrote:

Tomas Babej wrote:

Hi,

Any of the following checks:
   - overlap between primary RID range and secondary RID range
   - overlap between secondary RID range and secondary RID range

is performed now only if both of the ranges involved are local
domain ranges.

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

Tomas



So I assume in your reproduction steps the secondary range for both is 
0 hence the overlap?

Yes, that causes the issue.


rob


Tomas

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

Re: [Freeipa-devel] [PATCH] 0190 Fix installing server with external CA

2013-03-08 Thread Martin Kosek 

On 03/05/2013 05:27 PM, Jan Cholasta wrote:

On 5.3.2013 16:12, Jan Cholasta wrote:

Hi,

On 4.3.2013 15:29, Petr Viktorin wrote:

I did not test the external CA case when we merged DS instances some
time ago, so it ended up broken. Here is a fix.


Our DsInstance class could only be initialized properly by calling
create_instance or create_replica. Fr step 2, when the DS is not being
installed, I gathered the common setup code to init_info, and called
that. Ideally this will one day end up in __init__, but that's for a
bigger refactoring.


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



I have tried installing IPA with external CA with your patch several
times, and ipa-server-install always gets stuck while doing LDAP
updates. I am not really sure how these two are connected. Can you
please check if that happens to you on IPA from current master as well?

Honza



Turns out this was an error on my part. Sorry.

ACK.

Honza



Pushed to master, ipa-3.1.

Martin

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

Re: [Freeipa-devel] [PATCH 0038] Perform secondary rid range overlap check for local ranges

2013-03-08 Thread Tomas Babej 

On 03/08/2013 12:10 PM, Martin Kosek wrote:

On 03/05/2013 12:59 PM, Tomas Babej wrote:

Hi,

Any of the following checks:
   - overlap between primary RID range and secondary RID range
   - overlap between secondary RID range and secondary RID range

is performed now only if both of the ranges involved are local
domain ranges.

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



I think the patch is functionally OK (I tested it), I would just 
change the flow of the following:


@@ -194,19 +198,22 @@ static int ranges_overlap(struct range_info *r1, 
struct range_info *r2)

 r1-id_range_size, r2-id_range_size))
 return 2;

-/* check if secondary rid range overlaps with existing 
secondary rid range */

+/**
+ * The following 3 checks are relevant only if both ranges 
are local.
+ * Check if secondary rid range overlaps with existing 
secondary rid

+ * range. **/
 if (intervals_overlap(r1-secondary_base_rid, 
r2-secondary_base_rid,

-r1-id_range_size, r2-id_range_size))
+r1-id_range_size, r2-id_range_size)  local_ranges)
 return 3;
...


TO something like

...
/**
 * The following checks are relevant only if both ranges are 
local.
 * Check if secondary rid range overlaps with existing 
secondary rid

 * range. **/
if (local_ranges) {
... do the checks
}
...

Doing it your way, intervals_overlap() function is called 3 times when 
not needed + it is not so obvious that these checks are only done with 
local_ranges only.


Martin

Refactored.

Tomas
From 5bffce519949c5b394a2d0c4a09bd0d5d9b258bf Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 5 Mar 2013 09:17:20 +0100
Subject: [PATCH] Perform secondary rid range overlap check for local ranges
 only

Any of the following checks:
  - overlap between primary RID range and secondary RID range
  - overlap between secondary RID range and secondary RID range

is performed now only if both of the ranges involved are local
domain ranges.

https://fedorahosted.org/freeipa/ticket/3391
---
 .../ipa-range-check/ipa_range_check.c  | 37 ++
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
index 3a607636dc3ad9efc80ac7a2cef27eab524ad251..391e2259b6eced31fed399c927cfe44c1d3e237e 100644
--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
@@ -178,6 +178,11 @@ static int ranges_overlap(struct range_info *r1, struct range_info *r2)
 bool rid_ranges_set = (r1-base_rid != 0 || r1-secondary_base_rid != 0) 
   (r2-base_rid != 0 || r2-secondary_base_rid != 0);
 
+/**
+ * ipaNTTrustedDomainSID is not set for local ranges, use it to
+ * determine the type of the range **/
+bool local_ranges = r1-domain_id == NULL  r2-domain_id == NULL;
+
 bool ranges_from_same_domain =
  (r1-domain_id == NULL  r2-domain_id == NULL) ||
  (r1-domain_id != NULL  r2-domain_id != NULL 
@@ -185,8 +190,7 @@ static int ranges_overlap(struct range_info *r1, struct range_info *r2)
 
 /**
  * in case rid range is not set or ranges belong to different domains
- * we can skip rid range tests as they are irrelevant
- */
+ * we can skip rid range tests as they are irrelevant **/
 if (rid_ranges_set  ranges_from_same_domain){
 
 /* check if rid range overlaps with existing rid range */
@@ -194,20 +198,25 @@ static int ranges_overlap(struct range_info *r1, struct range_info *r2)
 r1-id_range_size, r2-id_range_size))
 return 2;
 
-/* check if secondary rid range overlaps with existing secondary rid range */
-if (intervals_overlap(r1-secondary_base_rid, r2-secondary_base_rid,
-r1-id_range_size, r2-id_range_size))
-return 3;
+/**
+ * The following 3 checks are relevant only if both ranges are local.
+ * Check if secondary rid range overlaps with existing secondary rid
+ * range. **/
+if (local_ranges){
+if (intervals_overlap(r1-secondary_base_rid,
+r2-secondary_base_rid, r1-id_range_size, r2-id_range_size))
+return 3;
 
-/* check if rid range overlaps with existing secondary rid range */
-if (intervals_overlap(r1-base_rid, r2-secondary_base_rid,
-r1-id_range_size, r2-id_range_size))
-return 4;
+/* check if rid range overlaps with existing secondary rid range */
+if (intervals_overlap(r1-base_rid, r2-secondary_base_rid,
+r1-id_range_size, r2-id_range_size))
+return 4;
 
-/* check if secondary rid range overlaps with existing rid range */
-if

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Rob Crittenden 

Sumit Bose wrote:

On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote:

Based on a comment from Sumit in ticket
https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline
of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags

There is a bit of hand waving going on around how the flags are
actually set inside the KDB plugin since I'm not at all familiar
with that code but I don't expect it to be too big a deal.

I'm not necessarily volunteering to do this work, just trying to
keep the ball moving forward.


Thank you for setting up the design page. I would like to suggest that
we should try to include all currently available flags in one run,
because:
- some flags related to OTP would be needed as well
- it is only a minor increase the development effort
- it is only a minor increase in the QE effort. Instead of doing
   * set/unset flag in CLI/WebUI
   * check with kdamin.local if the flag is in the expected state
   for a single attribute it has to be done for a list of attributes
   (maybe the steps can be added to a new 'How to test' section on the
   design page)
- it will help to find a good solution how to handle the flags in the
   CLI/WebUI

I think the last point is important because the flags are needed for all
Kerberos principals, i.e. users, hosts and services. Instead of adding a
list of new options/check boxes to each of the CLI commands/WebUI pages
it might be more helpful to handle the flags separately. The CLI can get
a new command class, e.g. krbflags. In the WebUI the Kerberos flags can be
shown and modified in a separate tab, I hope this will allow to use a
common template to users, hosts and services. These are only rough ideas
and suggestions, my point is that if we not only add a single flag but
about 15 it might be easier to find a good and usable interface to
modify them.


I'll update the page with these comments as well, eventually...

Ok, a new plugin makes sense, so we don't have to pollute all the other 
plugins with these flags.


One would need to pass in the object type they are dealing with:

ipa krbflags --type=user --ok-as-delegate=false sbose
ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com

We *could* avoid type potentially but it would expand our search base 
and could slow things down with lots of entries. We could search on the 
accounts container using (objectclass=ipaKrbPrincipal) and 
(|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something 
like that. I think I'd prefer specifying a type to avoid the case where 
someone has a hostname the same as a uid (we typically allow specifying 
non-fqdn when managing hosts).


As for setting all these flags, is this going to introduce oddball 
support issues if people start experimenting with turning somethings on 
and off? I really don't know. They can do it now using kadmin.local I 
suppose, and we aren't hearing any complaints.


Simo asked about upgrades. An interesting question.

So we'd have to sift through all the krbextradata to see if any of the 
flags we want to set are actually set and update LDAP. We may end up 
requiring a C tool to do this.


Mixing old and new backends could be supported during a transition 
period by setting the value both in the attribute and within 
krbextradata but we lack a way to do that in python AFAIK.


Doing this in a 398-ds plugin might be an easy way to support forwards 
and backwards compatibility, and it'd be C so we'd avoid all the python 
issues.


Adding the new schema and plugin should be the easy part.

rob

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

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Nathaniel McCallum 
On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote:
 On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote:
  Based on a comment from Sumit in ticket
  https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline
  of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags
  
  There is a bit of hand waving going on around how the flags are
  actually set inside the KDB plugin since I'm not at all familiar
  with that code but I don't expect it to be too big a deal.
  
  I'm not necessarily volunteering to do this work, just trying to
  keep the ball moving forward.
 
 Thank you for setting up the design page. I would like to suggest that
 we should try to include all currently available flags in one run,
 because:
 - some flags related to OTP would be needed as well

I'm not aware of any. Are you? I may very well be missing something
obvious.

Nathaniel


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

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Petr Spacek 

On 8.3.2013 16:45, Rob Crittenden wrote:

One would need to pass in the object type they are dealing with:

ipa krbflags --type=user --ok-as-delegate=false sbose
ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com

We *could* avoid type potentially but it would expand our search base and
could slow things down with lots of entries.
Correct me if I'm wrong, but our KDC driver usually does sub-tree search with 
base dc=example,dc=com. (Except some special cases.) Or not? :-)


 We could search on the accounts

container using (objectclass=ipaKrbPrincipal) and
(|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like
that. I think I'd prefer specifying a type to avoid the case where someone has
a hostname the same as a uid (we typically allow specifying non-fqdn when
managing hosts).
Would it be possible define some reasonable default value for --type? I 
don't like typing --service all the time ...


--
Petr^2 Spacek

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

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Sumit Bose 
On Fri, Mar 08, 2013 at 12:28:03PM -0500, Nathaniel McCallum wrote:
 On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote:
  On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote:
   Based on a comment from Sumit in ticket
   https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline
   of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags
   
   There is a bit of hand waving going on around how the flags are
   actually set inside the KDB plugin since I'm not at all familiar
   with that code but I don't expect it to be too big a deal.
   
   I'm not necessarily volunteering to do this work, just trying to
   keep the ball moving forward.
  
  Thank you for setting up the design page. I would like to suggest that
  we should try to include all currently available flags in one run,
  because:
  - some flags related to OTP would be needed as well
 
 I'm not aware of any. Are you? I may very well be missing something
 obvious.

iirc you once mentioned that requires_hwauth is used to signal the
client that an OTP is needed. But I haven't checked your recent code if
the flag is added behind the scenes or if it needs to be set for the
principal.

bye,
Sumit

 
 Nathaniel
 
 

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

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Nathaniel McCallum 
On Fri, 2013-03-08 at 18:53 +0100, Sumit Bose wrote:
 On Fri, Mar 08, 2013 at 12:28:03PM -0500, Nathaniel McCallum wrote:
  On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote:
   On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote:
Based on a comment from Sumit in ticket
https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline
of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags

There is a bit of hand waving going on around how the flags are
actually set inside the KDB plugin since I'm not at all familiar
with that code but I don't expect it to be too big a deal.

I'm not necessarily volunteering to do this work, just trying to
keep the ball moving forward.
   
   Thank you for setting up the design page. I would like to suggest that
   we should try to include all currently available flags in one run,
   because:
   - some flags related to OTP would be needed as well
  
  I'm not aware of any. Are you? I may very well be missing something
  obvious.
 
 iirc you once mentioned that requires_hwauth is used to signal the
 client that an OTP is needed. But I haven't checked your recent code if
 the flag is added behind the scenes or if it needs to be set for the
 principal.

We chose to abandon this since this flag is passed to the recipients of
the ticket and since OTP doesn't necessarily provide hardware guarantee.

Note that requires_hwauth is an RFC defined flag and admins may wish to
use it, so support for it should probably be present. However, it is
unrelated to OTP at this point.

Nathaniel


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

Re: [Freeipa-devel] [PROPOSAL] Kerberos flags

2013-03-08 Thread Rob Crittenden 

Petr Spacek wrote:

On 8.3.2013 16:45, Rob Crittenden wrote:

One would need to pass in the object type they are dealing with:

ipa krbflags --type=user --ok-as-delegate=false sbose
ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com

We *could* avoid type potentially but it would expand our search base and
could slow things down with lots of entries.

Correct me if I'm wrong, but our KDC driver usually does sub-tree search
with base dc=example,dc=com. (Except some special cases.) Or not? :-)


Yes but when we do that search we've got a full principal.

Consider the host plugin. If we are given a non-fully-qualified hostname 
we add the IPA domain by default when looking for things.


It is not uncommon for people to name their laptop after themselves.

So if we are told to add a flag to the pspacek principal, which one is 
it? The user pspacek or the host pspacek.example.com? Or we could 
require that hostnames are fully-qualified, it would just be a 
difference from other plugins.




  We could search on the accounts

container using (objectclass=ipaKrbPrincipal) and
(|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or
something like
that. I think I'd prefer specifying a type to avoid the case where
someone has
a hostname the same as a uid (we typically allow specifying non-fqdn when
managing hosts).

Would it be possible define some reasonable default value for --type?
I don't like typing --service all the time ...



Maybe, if we can assume what type of principal is most likely to be 
updated. Remember that the host/ principal is stored in a host, not a 
service record.


Then again, I don't know how often one is going to be adding flags to 
principals, so perhaps a required switch wouldn't be too onerous.


rob

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