Re: [Freeipa-devel] V4/Sub-CAs review

[Nalin Dahyabhai]

On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote:
> > > 7) 
> > > 
> > > How is a certificate going to be requested from a specific sub-CA using 
> > > the
> > > getcert command?
> > > 
> > I added a preliminary design; add a new certmonger property and
> > corresponding getcert-request(1) option for specifying the target
> > CA.
> > 
> > http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA
> 
> LGTM.

Ditto.  I prefer handling it as a separate property over turning the
profile name into a tuple.

Cheers,

Nalin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Added kpasswd_server directive in client krb5.conf

[Nalin Dahyabhai]

On Mon, Dec 21, 2015 at 12:17:08PM +0530, Abhijeet Kasurde wrote:
> Hi All,
> 
> Please review patches attached.

The port number should probably be changed from 749 to 464.

HTH,

Nalin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file

[Nalin Dahyabhai]

On Tue, Sep 02, 2014 at 10:18:12AM +0200, Jan Cholasta wrote:
 Dne 27.8.2014 v 16:49 David Kupka napsal(a):
 On 08/27/2014 11:22 AM, Jan Cholasta wrote:
 Dne 26.8.2014 v 15:55 Rob Crittenden napsal(a):
 David Kupka wrote:
 On 08/26/2014 03:08 PM, Jan Cholasta wrote:
 Hi,
 
 Dne 26.8.2014 v 13:01 David Kupka napsal(a):
 https://fedorahosted.org/freeipa/ticket/4481
 
 Doing this will break ipa-client-automount and ipa-certupdate, because
 they assume that api.env.host contains the hostname of the local
 system
 (which is the default value).
 
 It looked suspiciously simple so I could expect that there is some
 catch.
 
 There is obviously some confusion about what the option should
 represent
 (documentation says server hostname, code does client hostname),
 IMO we
 should resolve that first.
 
 Ok, are there any suggestions? What is the desired state?
 
 AIUI the server option is deprecated because it wasn't being used, not
 that it needed to be replaced. I believe that in most cases the server
 name is pulled from the xmlrpc_uri.
 
 Yes, that's what the ticket says:
 https://fedorahosted.org/freeipa/ticket/3071.
 
 Ok, adding 'host' entry with local host name.
 
 host has always meant the local host name.
 
 I think the man page is wrong.
 
 +1
 
 Fixing the line in man page.
 
 rob
 
 ACK as long as this works for Nalin.

The other half of this was cases where there's no ldap_uri set.  Just so
there's no confusion, if ldap_uri and/or server_uri are not set, what
are the recommended fallback settings that should be used for
constructing them?  I suspect it's server, then host, which is the
reverse of the order that they're currently being consulted, but I
figured I'd ask while we're all here.

Thanks,

Nalin

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

Re: [Freeipa-devel] [PATCH] 0008 Use certmonger D-Bus API instead of messing with its files.

[Nalin Dahyabhai]

On Wed, Sep 03, 2014 at 02:34:44PM +0200, Martin Kosek wrote:
 On 09/03/2014 02:07 PM, Jan Cholasta wrote:
  I was about to ask the same. Another option is to ask Nalin to update
  certmonger in F20.
 
 CCing Nalin. What is your take on this, do you plan to release it to F20.
 AFAIK, it is just stabilization/bugfixing release so it should fit there 
 nicely.

Assuming you don't hit any new bugs, yeah, that makes sense to me, too.
The current F21 candidate build (not in bodhi yet... I should get to
that) is probably what you'll see pop up for F20 as well.

HTH,

Nalin

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

Re: [Freeipa-devel] [PATCH] 0010 Add 'host' setting into default.conf configuration file

[Nalin Dahyabhai]

On Wed, Sep 03, 2014 at 04:25:00PM +0200, Martin Kosek wrote:
 On 09/03/2014 03:41 PM, Jan Cholasta wrote:
  ldap_uri is set only on servers, on clients you should use server (we
  should probably un-deprecate it). You could use host as a fallback, but it
  will only work on servers, as it points to the local host. IMO the right 
  order
  is server, then ldap_uri, then maybe host.
 
 BTW what happens when original server that the client enrolled with no longer
 exist and was replaced by some other server with other FQDN. Will certmonger
 fail in this case or will it fall back and do DNS SRV record to find
 alternative server like ipa command does?

It doesn't currently, but that certainly sounds like a reasonable thing
to ask for in a trac ticket or bugzilla.

Cheers,

Nalin

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

Re: [Freeipa-devel] Reasons for not using certmonger DBus API

[Nalin Dahyabhai]

On Thu, Jul 31, 2014 at 09:19:28AM +0200, Jan Cholasta wrote:
 If you mean host, yes, the man page says it's the server's hostname, but I
 don't think that's entirely true - it is currently set during server
 install, but it defaults to local hostname even on clients. IMO we could set
 it in ipa-client-install as well (at least when --hostname is used) and then
 ipa-submit could use it to construct the principal name.

Sounds workable to me (though, yikes, that means it's unsuitable for use
as a fallback when xmlrpc_uri isn't set, so that'll probably have to get
changed at the same time).  If there's a ticket for the client-install
change in IPA that I should follow and/or one for certmonger for the
rest of it, I can try to land it around the same time.

Thanks,

Nalin

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

Re: [Freeipa-devel] Reasons for not using certmonger DBus API

[Nalin Dahyabhai]

On Wed, Jul 30, 2014 at 04:28:50PM +0200, Jan Cholasta wrote:
 These two functions are used to force local hostname in certmonger. IMO the
 right thing to do here would be to drop these two functions and fix
 ipa-submit so that it reads the required configuration from
 /etc/ipa/default.conf.

Can you elaborate on that?  Either here or in a trac ticket or in
bugzilla?

The only hostname I see in the default.conf(5) man page is the name of
the server, which it should already be using when there's no xmlrpc_uri
set.

Nalin

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

Re: [Freeipa-devel] Reasons for not using certmonger DBus API

[Nalin Dahyabhai]

On Wed, Jul 30, 2014 at 03:51:08PM +0200, David Kupka wrote:
 In fact it is almost enough complete for us. The only operation I can't find
 is 'write ca_external_helper'.
 add_principal_to_cas and remove_principal_from_cas are modifying this entry
 in ca file. Certmonger provide 'get_location' DBus method that returns value
 of this entry but I can't find any 'set_location' method, writable property
 or other way to modify it over DBus.

Yeah, it wasn't originally expected that those'd need to be edited after
they were added.

 Am I searching wrong? If not I looked in certmonger code and think that I
 will be able to add the missing functionality. But I'm unsure what is the
 preferred way, I can think of two:
 1. set_location method
 2. read-write location/ca_external_helper property

Probably the latter, since it's slightly less code and I think more in
keeping with the way D-Bus clients generally expect to be doing things.
That's assuming you don't need to kill any in-progress attempts to
contact a CA and restart them with the new value.

Cheers,

Nalin

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

Re: [Freeipa-devel] Reasons for not using certmonger DBus API

[Nalin Dahyabhai]

On Wed, Jul 23, 2014 at 11:32:52AM +0300, Alexander Bokovoy wrote:
 Were there DBus Python bindings available in RHEL 5/6 at the time when the
 code was written?

Yes, but the API itself wasn't all there, and large parts of the
internals needed to be rewritten around its 0.53 release.  Before then,
it didn't expose _anything_ as properties.  The methods that return data
were all that it provided.

HTH,

Nalin

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

Re: [Freeipa-devel] Reasons for not using certmonger DBus API

[Nalin Dahyabhai]

On Wed, Jul 23, 2014 at 10:12:39AM +0200, Martin Kosek wrote:
 Certmonger API looked complete enough to pull this off:
 https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt
 
 If I am wrong, please tell me.

No, it's meant to be complete -- the getcert command only uses the APIs
to talk to the daemon, so they provide at least what it needs.

Two words of caution:
* That file's manually maintained, so it might not completely reflect
  what's available.  The introspection data's generated at runtime, so
  if you poke the service with an introspection request, or using
  d-feet, which does so under the covers, you might spot discrepancies.
  It probably goes without saying, but please report any that you find.
* The majority of properties are currently marked read-only, and you
  currently have to use the 'modify' API request to change them.  Mostly
  this is a result of 'getcert' not having needed anything more than
  that, and properties having been added after the initial versions, so
  it's not set in stone.

HTH,

Nalin

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

Re: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate

[Nalin Dahyabhai]

On Fri, Jun 27, 2014 at 06:19:25PM -0400, Rob Crittenden wrote:
 How it is monitoring with a ca-error I don't know.

If there's a previously-issued certificate present, the state machine
goes back to monitoring rather than the dead-end rejected state, so
that it'll try again later when certificate crosses the next enroll_ttl
threshold.

It's mainly a guess at the right thing to do in that situation (in case
the CA rejected the request for a transient reason that gets remedied at
the server at some point), so I'm not firmly wedded to it, and remain
open to changing it.

Now that I'm writing this, I'm thinking rejected requests should
probably be re-attempted, eventually, though it risks annoying the CA.

Cheers,

Nalin

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

Re: [Freeipa-devel] CA certificate renewal, shared store trust settings

[Nalin Dahyabhai]

On Fri, May 30, 2014 at 09:09:46AM +0200, Jan Cholasta wrote:
 On 29.5.2014 19:44, Nalin Dahyabhai wrote:
 I'm working on adding to certmonger the ability to read the IPA root
 certificate from the server and store it locally, and I'm looking at the
 V4 shared certificate store feature [1] with an eye toward also pulling
 down and processing those certificates.  Before I head down that path,
 I've got a few questions about the schema that the page describes for
 storing trust information.
 
 So, you want to fetch the certificates directly from LDAP? Shouldn't
 they rather be fetched using IPA API (in ipa-submit) or Dogtag API
 (in dogtag-ipa-renew-agent-submit)?

Yes, that's something the daemon is farming out to the enrollment
helpers.  As a start, though, I'm only looking at teaching ipa-submit to
fetch this information.

The IPA interfaces run over HTTPS, so I thought that having ipa-submit
search LDAP using GSSAPI would avoid complications that could arise if
the CA certificate had become invalid before we went to fetch things.

The request for the read the root certificate functionality is to have
something that works against servers running IPA on EL6, so the ability
to fetch the v3 root information is dictated by needing to work against
what we're already storing and offering there.

Accessing the additional information that's coming in v4 could be done
differently, but I'd also lean toward looking at the directory directly.
The design page mentions asking SSSD for it, which I guess would work.

 In the past few months that I worked on the CA certificate renewal
 feature the shared certificate store design has evolved into
 something more about certificate trust policy rather than simple
 storage of CA certificates. My plan is to integrate it with p11-kit
 in the forthcoming months to provide the policy to IPA clients. SSSD
 is going to be used as the component between IPA and p11-kit. A
 PKCS#11 module will be provided for (not only) that. (This is what
 http://www.freeipa.org/page/V4/CA_certificate_renewal_(2) is going
 to be about.)
 
 I can imagine you might as well talk to the module to fetch the CA
 certificates. Are there any plans to support PKCS#11 as a storage
 backend in certmonger?

Only notionally, as it it's only ever been one of those would be cool,
but we don't need it in the short-term things.  I also wasn't looking
forward to dealing with cases where a removable token isn't inserted
right when we intend to access it, but if we need to make that work,
then okay.

 This does not make me nervous at all. Take a look at other similar
 attributes in IPA, they all use directory string syntax. I'm open to
 suggestions, though.

The first thing that comes to mind is an enumerated syntax like the one
for booleans, but I understand that enforcing that would require help
from the server itself.  The docs tell me that syntax plugins are a
thing we can supply, but that might be more than we want to bite off.

 The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted'
 and 'distrusted', appears to map pretty directly to the sort of
 information that OpenSSL stores in trusted certificates [2], but going
 through the man pages for x509(1) and verify(1), I don't see anything
 that obviously corresponds to an ipaKeyTrust value of 'unknown'.   What's
 that value intended to signify, and how would consumers of the
 certificates be expected to treat certificates from entries with that
 ipaKeyTrust value?
 
 Actually it is designed to map to p11-kit-style trust policy 
 (http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html),
 which is a superset of OpenSSL's.

What's the planned schedule for teaching NSS and OpenSSL to consume
trust information supplied in this format?

 The unknown value means the trust is not explicitly given and that
 if there is other source of trust information for the
 key/certificate, it should be used. In p11-kit terms, it is for
 certificates which are neither in the anchors nor the blacklist set.
 In NSS terms, it's for certificates without any of the C, T, P or p
 trust flags.

Okay, that makes sense -- they're around for building chains, but not
much else.

 Are there examples of what the ipaKeyUsage attribute should contain?
 
 It's the purpose bit names from the key usage certificate extension
 (http://tools.ietf.org/html/rfc5280#section-4.2.1.3) or none.

So, enumerated values represented as directory strings?

 Is there a recommended method for mapping from this representation to
 the form that we'd pass to certutil(1)'s '-t' option when storing the
 certificates in NSS databases, or is the intent that it be translated
 into NSS-specific PKCS#11 attributes set on those certificates?
 
 Well, it can be both. But as I said above, I'm not sure if reading
 from LDAP directly is the best thing to do in this case.

[shrug]  If that's where it's being stored, something's going to have to
fetch it from there.  Until the SSSD and IPA interfaces

[Freeipa-devel] CA certificate renewal, shared store trust settings

[Nalin Dahyabhai]

I'm working on adding to certmonger the ability to read the IPA root
certificate from the server and store it locally, and I'm looking at the
V4 shared certificate store feature [1] with an eye toward also pulling
down and processing those certificates.  Before I head down that path,
I've got a few questions about the schema that the page describes for
storing trust information.

Is the ipaKeyTrust attribute meant to be a part of the ipaKeyPolicy
object class?

Looking at the ipaKeyTrust attribute, the description suggests that it's
a directoryString that should contain one of 'unknown', 'trusted', or
'distrusted' as its value.  The syntax doesn't guarantee that, and that
ambiguity makes me a little nervous.  Any chance of tweaking the schema
to remove that possibility?

The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted'
and 'distrusted', appears to map pretty directly to the sort of
information that OpenSSL stores in trusted certificates [2], but going
through the man pages for x509(1) and verify(1), I don't see anything
that obviously corresponds to an ipaKeyTrust value of 'unknown'.  What's
that value intended to signify, and how would consumers of the
certificates be expected to treat certificates from entries with that
ipaKeyTrust value?

Are there examples of what the ipaKeyUsage attribute should contain?

Is there a recommended method for mapping from this representation to
the form that we'd pass to certutil(1)'s '-t' option when storing the
certificates in NSS databases, or is the intent that it be translated
into NSS-specific PKCS#11 attributes set on those certificates?

Thanks,

Nalin

[1] 
http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store
[2] 
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html#openssl-trusted

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

[Freeipa-devel] [PATCH] BuildRequires: rhino in .spec file

[Nalin Dahyabhai]

When I try to scratch build master using 'make srpm' and koji, the build
log includes multiple errors like this:
  ../../util/make-ui.sh
  Error: Could not find or load main class 
org.mozilla.javascript.tools.shell.Main
  Error: Could not find or load main class 
org.mozilla.javascript.tools.shell.Main
  Error: Could not find or load main class 
org.mozilla.javascript.tools.shell.Main

Those classes are provided by the 'rhino' package in Raw Hide, so I
suggest adding it as a build-time requirement.

Nalin
From b8b146c09c9c77105f4f48743cd6d59ca6903f16 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Thu, 13 Mar 2014 17:09:49 -0400
Subject: [PATCH] Add missing dependency

We use Java classes which are bundled with rhino when uglifying
Javascript sources at build-time, so we need rhino at build-time.
---
 freeipa.spec.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index e851313..c17e939 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -74,6 +74,7 @@ BuildRequires:  check
 BuildRequires:  libsss_idmap-devel
 BuildRequires:  libsss_nss_idmap-devel
 BuildRequires:  java-1.7.0-openjdk
+BuildRequires:  rhino
 BuildRequires:  libverto-devel
 BuildRequires:  systemd
 BuildRequires:  libunistring-devel
-- 
1.9.0

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

[Freeipa-devel] Handling of multiple krbPrincipalNames and of krbCanonicalNames

[Nalin Dahyabhai]

Comparing master's ipa-kdb's handling of krbPrincipalName and
krbCanonicalName attributes with that of the upstream kldap driver,
there are a few differences which I'm thinking are bugs.

* If an entry has multiple krbPrincipalName values, the name which
  was used to look it up is required to match only the last value of the
  attribute that we read, not any of them.

* If an entry has a krbCanonicalName value, and the name which we used
  to look it up doesn't match it, if database aliases are allowed, we
  return an error instead of using it to populate the returned entry.

I'm attaching patches for both of these, though the second still doesn't
quite match the behavior of kldap.so, in that we don't preserve the
requested name if it differs from the canonical name only in case.  I
don't know that it matters, but I'm mentioning here just in case.

Cheers,

Nalin
From d4330cd204757bdbbcb50164d03fedf864d6b736 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 7 Oct 2013 15:24:29 -0400
Subject: [PATCH 1/4] Accept any alias, not just the last value

If the entry's krbPrincipalName attribute is multi-valued, accept any of
the values, not just the last one we happen to examine.
---
 daemons/ipa-kdb/ipa_kdb_principals.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c 
b/daemons/ipa-kdb/ipa_kdb_principals.c
index 38059d2..d3b2820 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -653,6 +653,9 @@ static krb5_error_code ipadb_find_principal(krb5_context 
kcontext,
 } else {
 found = (strcmp(vals[i]-bv_val, (*principal)) == 0);
 }
+if (found) {
+break;
+}
 }
 
 ldap_value_free_len(vals);
-- 
1.8.3.1

From 59c38ecfe3786c72b7fea9aeba2118f1d07f3235 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 7 Oct 2013 15:26:21 -0400
Subject: [PATCH 2/4] Restore krbCanonicalName handling

When an entry has a krbCanonicalName, if KRB5_KDB_FLAG_ALIAS_OK is set,
rewrite the principal name to the canonical value, else error out,
instead of always returning an error if the requested name doesn't look
like the canonical one.
---
 daemons/ipa-kdb/ipa_kdb_principals.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c 
b/daemons/ipa-kdb/ipa_kdb_principals.c
index d3b2820..766aa92 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -672,11 +672,7 @@ static krb5_error_code ipadb_find_principal(krb5_context 
kcontext,
 
 /* Again, if aliases are accepted by KDC, use case-insensitive 
comparison */
 if ((flags  KRB5_KDB_FLAG_ALIAS_OK) != 0) {
-if (ulc_casecmp(vals[0]-bv_val, vals[0]-bv_len,
-(*principal), strlen(*principal),
-NULL, NULL, result) != 0)
-return KRB5_KDB_INTERNAL_ERROR;
-found = (result == 0);
+found = true;
 } else {
 found = (strcmp(vals[0]-bv_val, (*principal)) == 0);
 }
-- 
1.8.3.1

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

Re: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store

[Nalin Dahyabhai]

On Tue, Sep 24, 2013 at 01:30:10PM +0200, Jan Cholasta wrote:
 We discussed this with Tomáš off-line and it turns out that
 ipa-client-install fails if the CA cert is not added to
 /etc/pki/nssdb.
 
 However, according to p11-kit docs it should work:
 http://p11-glue.freedesktop.org/doc/p11-kit/trust-nss.html. I
 wonder what needs to be done to make it work in IPA...

On my system, there's no symlink to libnssckbi.so (or the right location
in the link farm under /etc/alternatives) in /etc/pki/nssdb, so that
database isn't going to automatically pull in the list of trusted CAs
that p11-kit maintains.

Whether the database under /etc/pki/nssdb should automatically include
the usual set of trust anchors is probably a different conversation.

HTH,

Nalin

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

Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions

[Nalin Dahyabhai]

On Mon, Sep 09, 2013 at 10:05:59AM -0400, John Dennis wrote:
 On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote:
  I'd expect it to depend heavily on whether or not you're chaining up to
  an external CA.  Personally, I'd very much want to keep a different set
  of trust anchors for PKINIT in that situation.
 
 If you've got an external CA you still effectively have one trust anchor
 that can be revoked because we create a sub-CA from the external CA. Or
 perhaps I misunderstood what you were suggesting.

My main concern is that the external CA, having issued one sub CA to us,
can do so again for another customer, and trusting certificates because
they chain up to that CA also allows that CA's other clients to issue
certificates that we'd then also automatically trust.

We can't revoke such certificates (which is done by noting the
combination of issuer and serial number) until we know about them, and
we'll only know about one of them after someone's used it to attempt to
authenticate, possibly successfully.

Cheers,

Nalin

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

Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions

[Nalin Dahyabhai]

On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote:
 Good point. Isn't there an X509 extension (possibly part of PKIX?) which
 restricts membership in the chain path to a criteria. In other words you
 can require your sub-CA to be present in the chain. Sorry, but my memory
 is a bit fuzzy on this.

If you're talking about Name Constraints, they seem to be geared more
toward allowing a CA to limit what a sub CA that it issues can be
trusted to do, and not the other way around.

I don't think I know of anything that deals with this that doesn't
eventually end up setting up library-specific configuration for the
library that's going to be verifying the certificate.

Nalin

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

Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions

[Nalin Dahyabhai]

On Mon, Sep 09, 2013 at 01:07:09PM -0700, Henry B. Hotz wrote:
 On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai na...@redhat.com wrote:
  On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote:
  Good point. Isn't there an X509 extension (possibly part of PKIX?) which
  restricts membership in the chain path to a criteria. In other words you
  can require your sub-CA to be present in the chain. Sorry, but my memory
  is a bit fuzzy on this.
  
  If you're talking about Name Constraints, they seem to be geared more
  toward allowing a CA to limit what a sub CA that it issues can be
  trusted to do, and not the other way around.
 
 Aren't the implementations of name constrains generally buggy, and therefore 
 not usable in real life?

Yes, ISTR hearing that library support for them was not as widespread as
I'd have hoped.

There's also the secondary problem that the standards don't specify how
to express Name Constraints on AnotherName values, for example Kerberos
principal names.  Though it's possible I just haven't found where that
was done.

Cheers,

Nalin

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

Re: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains

[Nalin Dahyabhai]

On Mon, Aug 05, 2013 at 03:45:06PM +0300, Alexander Bokovoy wrote:
 OK, fair enough. I did use of libsss_nss_idmap optional. For tests I
 think we need to involve nsswrapper here to make sure of a predictable
 testing.
 
 I've added:
 
   --with-nsswitch use nsswitch API to look up users and groupsnot
   found in the LDAP
   --with-sss-nss-idmapuse libsss_nss_idmap to discover SIDs. Requires
   --with-nsswitch as well
   --with-pam  use PAM API to authenticate users not found in the
   LDAP. Requires --with-nsswitch as well
 
 And also split PAM use -- if --with-nsswitch is provided, you may
 optionally disable use of PAM.

I like where this is going, but the configure logic looks a bit off.

In HEAD~9, if configure is passed --without-nsswitch, $use_nsswitch will
be set to no, so the conditional USE_NSSWITCH will be enabled.  The
USE_PAM conditional's based on $use_nsswitch instead of $use_pam, which
looks like a copy/paste error.

The subsequent call to check the contents of $USE_NSSWITCH should
probably be changed to check $use_nsswitch, as automake conditionals
don't set variables in configure that are named after the conditionals.
Likewise for $USE_PAM and $use_pam.

 I also moved src/back-sch-sssd.c to src/back-sch-nss.c to reflect that
 and renamed SSSD references to NSSWITCH.

Ok.  Some line wrapping adjustments appear to still be needed.

 HEAD~7:
 * Fix formatting of wrapped lines when calling 
 backend_shr_get_vattr_str().
 * Check for errors when converting the configured sssd_min_id to a number
 by switching from atol() to strtol() or strtoul().
 done.
 
 Looks good, except that the comment in the checking block implies that
 it's imposing a lower limit on ret.sssd_min_id, when it's reassigning
 the default in case of a parsing error.  If the value parses as valid,
 it appears that a value lower than 1000 would be accepted.
 That's OK because it is a configuration option. If you want to have it set
 to something like 500, so be it -- not all distributions enforce 1000
 as their defaults.

That's fine by me.  Please correct the comment to reflect the intent.

 HEAD~6:
 * Drop extra whitespace after the type of the name member when
 defining struct backend_search_filter_config.
 * backend_search_filter_has_cn_uid() allocates config-name using
 slapi_ch_malloc(), but it is later freed by free().
 * backend_retrieve_user_entry_from_sssd(): fix line wrapping in
 function signature.
 * backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors.
 * backend_retrieve_user_entry_from_sssd(): avoid using
 slapi_entry_attr_set_int(), which will treat an unsigned 32-bit
 with the high bit set as a negative value
 * backend_retrieve_user_entry_from_sssd(): check for zero-length
 pw_shell value, and avoid adding it as a loginShell value, since
 that'd be invalid
 all done.
 
 That last one's just a NULL check now.  Please add a check for a
 zero-length value, which would also be skipped.  Otherwise, looks good.
 Done.

Good.  One thing I just noticed: in backend_search_filter_has_cn_uid(),
is there a guarantee that bval-bv_val is NUL-terminated when it's being
passed to strcasecmp()?  If not, it could cause problems later.

 * backend_retrieve_group_list_from_sssd(): check for NULL result from
 realloc().
 
 Leaks are possible if realloc() fails for grouplist or entries.
 I've used a temporary variable to realloc() into and then only change
 'entries' if its value is not NULL. This should handle the case.

I see it being handled for 'entries' now, but not where it's being done
for 'grouplist'.

 * backend_search_cb() now appears to be freeing the closest-match
 as part of a conditional clause, right before it would unconditionally
 do so.
 removed the duplicate. My original intent in moving that code was to
 avoid freeing closest-match right before we are printing it with
 slapi_log_error() and then sending the result with send_ldap_result():
 https://git.fedorahosted.org/cgit/slapi-nis.git/tree/src/back-sch.c#n1219
 
 I can revert this part back if you wish but I think there is an error in
 the original code.
 
 The current intent there is to avoid sending a closest-match DN when
 we're returning entries as part of the result, to only send such a value
 as part of the result if we're sending back an LDAP_NO_SUCH_OBJECT
 error.
 My main issue with this is that for the case when we found the entry we
 still show the debug message with 'closest match = (null)'. I think it
 is misleading at least.

Oh, that's the error you were referring to.  Yeah, we should fix that.  

 ... and I did fix couple more comments received from Sumit:
 
 1. switched to use usigned long for sssd_min_id
 2. added initializer for 'dn' in 
 backend_retrieve_user_entry_from_sssd()/backend_retrieve_group_entry_from_sssd
 3. switched to atoll() with cast of the result to (uid_t)/(gid_t) because
we already know at staging phase 

Re: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains

[Nalin Dahyabhai]

Crikey, that was fast.

On Fri, Aug 02, 2013 at 04:44:33PM +0300, Alexander Bokovoy wrote:
 On Thu, 01 Aug 2013, Nalin Dahyabhai wrote:
 HEAD~10:
 * Add internal whitespace when computing the value to pass to
 slapi_ch_malloc().
 * Break the declaration and initialization of str into two lines.
 * Use '\0' to terminate str instead of 0.
 * In the new comment in format.h, NULL should be NUL.
 done

Ok, good.

 HEAD~8:
 * In configure.in, drop the hunk that changes the version number that we
 pass to AC_INIT.
 * In configure.in, one test compares x$use_sss_nss_idmap != xno, while
 one shortly after compares $use_sss_nss_idmap = yes.  If
 $use_sss_nss_idmap can be empty, then the second test needs to be
 ready for that.

Good.

 * The help text still refers to SSSD specifically, when the code doesn't
 enforce or guarantee that SSSD's involved when performing nsswitch
 lookups or PAM authentication.
 
 The whole setup really makes sense only when SSSD is in use. Aside from
 that, the whole setup is triggered only if we find libsss_nss_idmap
 library which is provided by SSSD. Yes, it is used for an optional
 adding of the SID but linking is explicit.

Yeah, but why is all of that required?  If we want to be able to gateway
whatever's going on at the server, the ipaNTSecurityIdentifier lookup is
already optional at runtime.  Making that part optional at compile-time
would make the rest of the code (at least the nsswitch parts) easier to
self-test.

 HEAD~7:
 * Fix formatting of wrapped lines when calling backend_shr_get_vattr_str().
 * Check for errors when converting the configured sssd_min_id to a number
 by switching from atol() to strtol() or strtoul().
 done.

Looks good, except that the comment in the checking block implies that
it's imposing a lower limit on ret.sssd_min_id, when it's reassigning
the default in case of a parsing error.  If the value parses as valid,
it appears that a value lower than 1000 would be accepted.

 HEAD~6:
 * Drop extra whitespace after the type of the name member when
 defining struct backend_search_filter_config.
 * backend_search_filter_has_cn_uid() allocates config-name using
 slapi_ch_malloc(), but it is later freed by free().
 * backend_retrieve_user_entry_from_sssd(): fix line wrapping in
 function signature.
 * backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors.
 * backend_retrieve_user_entry_from_sssd(): avoid using
 slapi_entry_attr_set_int(), which will treat an unsigned 32-bit
 with the high bit set as a negative value
 * backend_retrieve_user_entry_from_sssd(): check for zero-length
 pw_shell value, and avoid adding it as a loginShell value, since
 that'd be invalid
 all done.

That last one's just a NULL check now.  Please add a check for a
zero-length value, which would also be skipped.  Otherwise, looks good.

 * backend_retrieve_user_entry_from_sssd() adds ipaNTUserAttrs as an
 objectClass in the temporary entry, but the value isn't copied into
 the cache.  What purpose does it serve?
 I removed this part since we are anyway using extensibleObject for the
 generated entry.

Makes sense.

 * backend_retrieve_user_entry_from_sssd(): extra whitespace when
 constructing the new entry's DN.

Both of these still have an extra space after the assignment operator.

 * backend_retrieve_user_entry_from_sssd(): memory leak from not freeing
 the result of slapi_escape_filter_value().
 * backend_retrieve_group_entry_from_sssd(): fix line wrapping in
 function signature.
 * backend_retrieve_group_entry_from_sssd() needs to handle ERANGE errors.
 * backend_retrieve_group_entry_from_sssd(): extra whitespace when
 constructing the new entry's DN.
 * backend_retrieve_group_entry_from_sssd(): memory leak from not freeing
 the result of slapi_escape_filter_value().
 all done

Otherwise, looks good.

 * backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors.
 * backend_retrieve_group_entry_from_sssd(): avoid using
 slapi_entry_attr_set_int(), which will treat an unsigned 32-bit
 with the high bit set as a negative value
 * backend_retrieve_group_list_from_sssd(): check for NULL result from
 realloc().

Leaks are possible if realloc() fails for grouplist or entries.

 * backend_search_sssd(): fix line wrapping for call to
 slapi_filter_apply().
 * backend_search_sssd(): use strtol() or strtoul() to convert a value to
 a number, and check for errors.
 * backend_search_sssd(): staged-container_sdn/map_group/map_set are
 allocated with slapi_ch_strdup() but freed with free() later.
 * backend_retrieve_from_sssd(): check for NULL result from malloc().
 * backend_retrieve_from_sssd(): fix line wrapping for calls to
 backend_retrieve_user/group_entry_from_sssd.
 all done

Otherwise, looks good.

 HEAD~5:
 * free_pam_response() uses slapi_ch_free() to free memory that was
 probably allocated with malloc().
 * pam_conv_func(): remove extra whitespace in call to slapi_pblock_get()
 * pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate

Re: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains

[Nalin Dahyabhai]

On Wed, Jul 31, 2013 at 03:53:21PM +0300, Alexander Bokovoy wrote:
 Authentication is handled for both IPA and trusted domain users. The
 former case requires some specific handling of the SLAPI_BIND_TARGET_SDN
 to rewrite it to the original entry's DN. As result successful bind
 looks like this in the dirsrv logs:
 [31/Jul/2013:15:49:03 +0300] conn=15 fd=79 slot=79 SSL connection from 
 192.168.111.216 to 192.168.111.216
 [31/Jul/2013:15:49:03 +0300] conn=15 SSL 256-bit AES
 [31/Jul/2013:15:49:03 +0300] conn=15 op=0 BIND 
 dn=uid=admin,cn=users,cn=compat,dc=example,dc=com method=128 version=3
 [31/Jul/2013:15:49:03 +0300] conn=15 op=1 SRCH base=dc=example,dc=com 
 scope=2 filter=(uid=foobar) attrs=ALL
 [31/Jul/2013:15:49:03 +0300] conn=15 op=0 RESULT err=0 tag=97 nentries=0 
 etime=0 dn=uid=admin,cn=users,cn=accounts,dc=example,dc=com

The RESULT dn being different from the BIND dn is easy to miss, but it
should prevent possible problems where a given user can be bound to more
than one DN, depending on where they started, so I guess it's fine.

On to specific patches:
HEAD~11 looks fine.
HEAD~10:
* Add internal whitespace when computing the value to pass to
  slapi_ch_malloc().
* Break the declaration and initialization of str into two lines.
* Use '\0' to terminate str instead of 0.
* In the new comment in format.h, NULL should be NUL.
HEAD~9 looks fine.
HEAD~8:
* In configure.in, drop the hunk that changes the version number that we
  pass to AC_INIT.
* In configure.in, one test compares x$use_sss_nss_idmap != xno, while
  one shortly after compares $use_sss_nss_idmap = yes.  If
  $use_sss_nss_idmap can be empty, then the second test needs to be
  ready for that.
* The help text still refers to SSSD specifically, when the code doesn't
  enforce or guarantee that SSSD's involved when performing nsswitch
  lookups or PAM authentication.
HEAD~7:
* Fix formatting of wrapped lines when calling backend_shr_get_vattr_str().
* Check for errors when converting the configured sssd_min_id to a number
  by switching from atol() to strtol() or strtoul().
HEAD~6:
* Drop extra whitespace after the type of the name member when
  defining struct backend_search_filter_config.
* backend_search_filter_has_cn_uid() allocates config-name using
  slapi_ch_malloc(), but it is later freed by free().
* backend_retrieve_user_entry_from_sssd(): fix line wrapping in
  function signature.
* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors.
* backend_retrieve_user_entry_from_sssd(): avoid using
  slapi_entry_attr_set_int(), which will treat an unsigned 32-bit
  with the high bit set as a negative value
* backend_retrieve_user_entry_from_sssd(): check for zero-length
  pw_shell value, and avoid adding it as a loginShell value, since
  that'd be invalid
* backend_retrieve_user_entry_from_sssd() adds ipaNTUserAttrs as an
  objectClass in the temporary entry, but the value isn't copied into
  the cache.  What purpose does it serve?
* backend_retrieve_user_entry_from_sssd(): extra whitespace when
  constructing the new entry's DN.
* backend_retrieve_user_entry_from_sssd(): memory leak from not freeing
  the result of slapi_escape_filter_value().
* backend_retrieve_group_entry_from_sssd(): fix line wrapping in
  function signature.
* backend_retrieve_group_entry_from_sssd() needs to handle ERANGE errors.
* backend_retrieve_group_entry_from_sssd(): extra whitespace when
  constructing the new entry's DN.
* backend_retrieve_group_entry_from_sssd(): memory leak from not freeing
  the result of slapi_escape_filter_value().
* backend_retrieve_group_entry_from_sssd() adds ipaNTGroupAttrs as an
  objectClass in the temporary entry, but the value isn't copied into
  the cache.  What purpose does it serve?
* backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors.
* backend_retrieve_group_entry_from_sssd(): avoid using
  slapi_entry_attr_set_int(), which will treat an unsigned 32-bit
  with the high bit set as a negative value
* backend_retrieve_group_list_from_sssd(): check for NULL result from
  realloc().
* backend_search_sssd(): fix line wrapping for call to
  slapi_filter_apply().
* backend_search_sssd(): use strtol() or strtoul() to convert a value to
  a number, and check for errors.
* backend_search_sssd(): staged-container_sdn/map_group/map_set are
  allocated with slapi_ch_strdup() but freed with free() later.
* backend_retrieve_from_sssd(): check for NULL result from malloc().
* backend_retrieve_from_sssd(): fix line wrapping for calls to
  backend_retrieve_user/group_entry_from_sssd.
HEAD~5:
* free_pam_response() uses slapi_ch_free() to free memory that was
  probably allocated with malloc().
* pam_conv_func(): remove extra whitespace in call to slapi_pblock_get()
* pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate
  replies, because plugins tend to be use free() to free them.
* pam_conv_func(): replace if/else-if/else-if/else-if stacks with a
  switch() statement.
* 

Re: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains

[Nalin Dahyabhai]

Apologies for the delay.

On Mon, Jul 15, 2013 at 08:30:03PM +0300, Alexander Bokovoy wrote:
 Here is the logic:
 
 0. Configuration is performed by setting
 
schema-compat-lookup-sssd: user|group
schema-compat-sssd-min-id: value
 
 in corresponding schema-compat plugin tree (cn=users and cn=groups).
 
 If schema-compat-sssd-min-id is not set, it will default to 1000. It is
 used to filter out attempts to fetch system users (1000 on Fedora by
 default).
 
 1. On query, we parse query filter to identify what type of request is
 this: user or group lookup and then issue getpwnam_r()/getgrnam_r() and
 getsidbyid() for libsss_nss_idmap to fetch all needed information.
 
 SSSD caches these requests they should be relatively fast.
 
 2. Once we served the request, it is cached in schema-compat cache map.
 The entry in the cache is currently not expired explicitly but I'm
 working on expiring it on wrong authentication -- if PAM stack returns a
 response telling there is no such user.
 
 3. Authentication bind for cached entries is done via PAM service
 'system-auth'. If HBAC rule 'allow_all' is disabled in FreeIPA, one
 needs to create a rule with service 'system-auth' and allow all users to
 access it on IPA masters. Since system-auth is never used explicitly by
 any application (it is always included through PAM stack and only
 top-level PAM service is used to drive the HBAC ruleset), there is no
 problem.
 
 PAM authentication code is taken from pam_passthru DS plugin. We cannot
 use it unchanged because pam_passthru expects that LDAP entry will exist
 in DS, while it is not true for these synthetic entries representing
 trusted domain users.
 
 On Fedora one needs pam-devel and libsss_nss_idmap-devel to build the
 plugin with new functionality.

The bits about how to configure this facility need to be in the
documentation somewhere.  Right now there is none being added, and no
new self-tests.

 diff --git a/configure.ac b/configure.ac
 index 8d7cbe1..4a47d36 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -309,6 +309,47 @@ AC_SUBST(ASYNCNS_CFLAGS)
  AC_SUBST(ASYNCNS_LIBS)
  fi
  
 +AC_ARG_WITH(sss_nss_idmap,
 + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]),
 + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO)
 +if pkg-config sss_nss_idmap 2 /dev/null ; then
 + if test x$use_sss_nss_idmap != xno ; then
 + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have 
 libsss_nss_idmap.])
 + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap)
 + else
 + SSS_NSS_IDMAP_CFLAGS=
 + SSS_NSS_IDMAP_LIBS=
 + fi
 +else
 + if test $use_sss_idmap = yes ; then

Should this reference to $use_sss_idmap be referring to
$use_sss_nss_idmap instead?

 + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap)
 + else
 + SSS_NSS_IDMAP_CFLAGS=
 + SSS_NSS_IDMAP_LIBS=
 + fi
 +fi
 +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x])

I suspect this'll need to quote SSS_NSS_IDMAP_LIBS here, in case its
value ever starts to include whitespace.

 +if x$SSS_NSS_IDMAP_LIBS != x ; then

Likewise here.

 + AC_CHECK_HEADERS(pam.h)
 + if test x$ac_cv_header_pam_h = xno ; then
 + use_pam=yes
 + else
 + use_pam=no
 + fi
 +
 + if test $use_pam = yes ; then
 + PAM_CFLAGS=
 + PAM_LIBS=-lpam
 + else
 + AC_ERROR([pam.h not found and it is required for SSSD mode])
 + fi
 + AC_SUBST(PAM_CFLAGS)
 + AC_SUBST(PAM_LIBS)
 +fi

Jakub already noted that this should be checking for
security/pam_appl.h.

 @@ -401,6 +442,13 @@ 
 AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_RDN_ATTR,$rdnattr,
  attrattr=schema-compat-entry-attribute
  AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_ATTR_ATTR,$attrattr,
  [Define to name of the attribute which is used to specify 
 attributes to be used when constructing entries.])
 +sssdattr=schema-compat-lookup-sssd
 +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_ATTR,$sssdattr,
 +[Define to name of the attribute which dictates whether or 
 not SSSD on FreeIPA master is consulted about trusted domains' users.])

Is this a boolean attribute?

 diff --git a/src/back-sch-pam.c b/src/back-sch-pam.c
 new file mode 100644
 index 000..3266261
 --- /dev/null
 +++ b/src/back-sch-pam.c
 @@ -0,0 +1,361 @@
 +/** BEGIN COPYRIGHT BLOCK
 + * This Program is free software; you can redistribute it and/or modify it 
 under
 + * the terms of the GNU General Public License as published by the Free 
 Software
 + * Foundation; version 2 of the License.
 + *
 + * This Program is distributed in the hope that it will be useful, but 
 WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
 FITNESS
 + * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more 
 details.
 + *
 + * You should have received a copy of the GNU 

Re: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains

[Nalin Dahyabhai]

On Tue, Jul 23, 2013 at 10:15:47AM +0300, Alexander Bokovoy wrote:
 On Tue, 23 Jul 2013, Nalin Dahyabhai wrote:
 Apologies for the delay.
 Thanks for the review!
 
 One short comment -- PAM code is from PAM pass-through plugin from
 389-ds. That's the reason why its code doesn't follow slapi-nis way and
 why it has that license. I tried to keep it mostly intact to share
 changes but looking at git log it gets roughly two commits per year so
 maybe it is better to rework it completely.

That'd be my preference.  Other than knowing how to map specific
PAM error codes to LDAP-level errors, there doesn't seem to be a lot of
magic that needs to be preserved in there.

 I'll address other comments and will send updated version for the
 review today. This was my first sizable SLAPI code so errors are
 inevitable.

No worries.  I think there's already a lot in there that's right.

I've been thinking about the patch some more, and I need to revise a
couple of my comments.

[snip]
 +   slapi_entry_add_string(entry,
 +  uid, user_name);
 
 If is_uid is true, this is a numeric string.  Intentional?

Given that group entries are being constructed using group member
information, which is always login names, I guess it isn't.

[snip]
 +   for (i=0; grp.gr_mem[i]; i++) {
 +   slapi_entry_add_string(entry, memberUid,
 +   slapi_ch_smprintf(uid=%s,%s, grp.gr_mem[i], 
 sdn));
 +   }
 
 The memberUid attribute doesn't typically contain DNs.  Did you mean
 to use member here?  Or to just use the user login name for the value?

This probably wants to set memberUid to the grp.gr_mem element's
value, because if we construct a member DN and expect the plugin's
configured logic to dereference it and pull out the UID value, and the
plugin attempts to read the entry with that DN by doing a search with
scope=base to find the entry, I don't think it'll trigger the logic that
would create that entry in the cache.

That, and in compat trees we're generally in the business of unrolling
group memberships anyway.

Cheers,

Nalin

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

Re: [Freeipa-devel] [PATCH] 1079 address CA subsystem renewal issues

[Nalin Dahyabhai]

On Fri, Jan 11, 2013 at 06:49:08PM -0500, Rob Crittenden wrote:
 Revised patch that takes advantage of new version of certmonger.
 certmonger-0.65 adds locking from the time renewal begins to the end
 of the post_save_command.

A note:  the lock isn't obtained until after we've obtained a
certificate from a CA, and we're ready to save it to the specified
location.

That's why attempting to renew multiple certificates at the same time
can result in transient CA-unreachable errors being encountered for some
of them: while we're attempting to obtain one certificate, we may also
be restarting the CA as part of the process of saving one that we've
already obtained.

In these cases, the daemon will try to contact the CA again later, so it
should all sort itself out in the end.

HTH,

Nalin

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

Re: [Freeipa-devel] [PATCH] 1072 enable transaction support

[Nalin Dahyabhai]

On Tue, Nov 20, 2012 at 02:08:04PM +0100, Martin Kosek wrote:
 4) nsslapd-pluginbetxn is not set for schema compatibility plugin after 
 upgrade:
 
 # Schema Compatibility, plugins, config
 dn: cn=Schema Compatibility,cn=plugins,cn=config
 nsslapd-pluginId: schema-compat-plugin
 cn: Schema Compatibility
 objectClass: top
 objectClass: nsSlapdPlugin
 objectClass: extensibleObject
 nsslapd-pluginDescription: Schema Compatibility Plugin
 nsslapd-pluginEnabled: on
 nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/schemacompat-plugin.so
 nsslapd-pluginVersion: 0.44 (betxn support available and enabled by default)
 nsslapd-pluginVendor: redhat.com
 nsslapd-pluginType: object
 nsslapd-pluginInitfunc: schema_compat_plugin_init
 
 This is supposed to be enabled by default, judging by nsslapd-pluginVersion
 description, but this may create an inconsistency between new installs and
 upgraded IPA servers.
 
 The same issue applies to IPA server with NIS plugin enabled.

Which version of IPA is it that starts explicitly configuring
nsslapd-pluginbetxn values for plugins?

For Fedora, at least, are there cases where we're going from a version
that didn't configure that setting to a version that does configure it,
as an update within a single release?  If not, I can make the default
change depending on which release we're building for, and we'll be fine.
If that sort of upgrade is expected, though, the package will probably
need to start conflicting with versions of IPA that don't configure
nsslapd-pluginbetxn one way or the other, because there's no default
value that's guaranteed to be safe.

Nalin

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

Re: [Freeipa-devel] [PATCH] 1072 enable transaction support

[Nalin Dahyabhai]

On Thu, Nov 15, 2012 at 11:53:44PM -0500, Rob Crittenden wrote:
 In order for this to work you'll need to apply the last two patches
 (both 0001) to slapi-nis and spin it up yourself, otherwise you'll
 have serious deadlock issues. I know this is extra work but this
 patch is potentially disruptive so I figure the earlier it is out
 the better.
 
 Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may
 have been too aggressive in my cleanup.
 
 Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch?
 
 Once we have an official slapi-nis build with these patches we'll
 need to set the minimum n-v-r in our spec file.

Rob, the original patch was already applied.  I since reworked large
parts of how it was organized to make it easier for me to read, and
tagged the result as 0.43.  Have you tested the IPA changes in
combination with the 0.44 builds from either ipa-devel or Fedora 18's
updates-testing repository?

Nalin

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

Re: [Freeipa-devel] slow response

[Nalin Dahyabhai]

On Fri, Oct 05, 2012 at 12:02:52PM -0700, Stephen Ingram wrote:
 As I'm thinking this might also solve my IPA large memory usage issue,
 I've been following this bug and see there is now a patch for it. I
 also see it is in QA along with several other IPA-related (and
 non-IPA-related) Kerberos fixes.

That group is currently slated for a later update.

  I thought at some point an errata
 release would happen during the RHEL 6.3 time-frame, but as I'm not
 too familiar with how this works, so I'm not sure. Is this a
 possibility, or are these being held back for some reason like
 additional QA time?

The isolated fix was pushed as RHBA-2012:1294.

Cheers,

Nalin

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

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

[Nalin Dahyabhai]

On Mon, Sep 10, 2012 at 04:58:40PM -0400, Rob Crittenden wrote:
 certificate renewal failed. I spent far too long trying to figure
 out why tomcat wasn't listening on port 9180 but failed. I think
 9180 is actually the old server, right? So another missing
 dependency on a fixed certmonger?
 
 The best I could find was the certmonger error:
 
 ca-error: Error 7 connecting to
 http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't
 connect to server.

That's the old port, alright, though I thought the upgrade process
wasn't going to be converting already-installed Dogtag instances.
Anyway, if your IPA configuration says dogtag_version = 10,
certmonger's not going to notice it until version 0.60.  I've just set
the wheels in motion to push that version to Fedora 17 and later.

HTH,

Nalin

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

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

[Nalin Dahyabhai]

On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote:
 Incidentally, I ran this in permmissive selinux mode.  The following
 rules are required to be added:
 
 #= certmonger_t ==
 corenet_tcp_connect_http_cache_port(certmonger_t)
 files_read_var_lib_symlinks(certmonger_t)

On my system, semanage port -l shows me:
 http_cache_port_t  tcp  8080, 8118, 10001-10010

Are these ports already labeled this way for Dogtag, or is it a
coincidental overlap with some other package?  If it's an overlap,
it might be better to switch to using ports which aren't already labeled
for use in policy that applies to some other package.

If not, please open a bug against the selinux-policy component to get
these accesses added to the set that's allowed by the default policy.

Nalin

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

Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

[Nalin Dahyabhai]

On Wed, Sep 05, 2012 at 05:08:12PM -0400, Ade Lee wrote:
 On Wed, 2012-09-05 at 16:43 -0400, Nalin Dahyabhai wrote:
  On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote:
   Incidentally, I ran this in permmissive selinux mode.  The following
   rules are required to be added:
   
   #= certmonger_t ==
   corenet_tcp_connect_http_cache_port(certmonger_t)
   files_read_var_lib_symlinks(certmonger_t)
  
  On my system, semanage port -l shows me:
   http_cache_port_t  tcp  8080, 8118, 10001-10010
  
  Are these ports already labeled this way for Dogtag, or is it a
  coincidental overlap with some other package?  If it's an overlap,
  it might be better to switch to using ports which aren't already labeled
  for use in policy that applies to some other package.
 
 We have specifically chosen to use what would be the default ports for
 tomcat.  These ports are already labeled as you have described above.
 We have adjusted our selinux policy to handle that.  In fact, we are now
 extending a tomcat selinux domain provided by the system policies, and
 this tomcat domain allows access to those ports.

My thinking, based on the name, is that the policy expects this set of
ports to be used by squid, and actual HTTP caches, rather than arbitrary
servlet containers.  But then I suppose the policy maintainer will know
better.  Please CC me on the policy bug so that I can keep an eye on it.

Thanks,

Nalin

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

Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates

[Nalin Dahyabhai]

On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote:
 Use the new certmonger capability to be able to renew the dogtag
 subsystem certificates (audit, OCSP, etc).

Are the copies of the certificates in the pki-ca CS.cfg file being
updated elsewhere?  Or is it not turning out to be a problem if they
aren't?

Nalin

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

Re: [Freeipa-devel] [PATCH] compat ieee802Device entries for ipaHost entries

[Nalin Dahyabhai]

On Tue, Apr 24, 2012 at 12:03:31PM +0200, Jan Cholasta wrote:
 I did some more testing and found out that this line:
 
 default:schema-compat-entry-rdn: 'cn=%first(%{fqdn})'
 
 needs to be changed to:
 
 default:schema-compat-entry-rdn: cn=%first(%{fqdn})
 
 in both install/share/schema_compat.uldif and
 install/updates/10-schema_compat.update, otherwise we get entries
 with DN like this:
 'cn=test.example.com',cn=computers,cn=compat,dc=example,dc=com.
 
 Besides this, both clean installs and upgrades seem to work fine
 with this patch.

Right, the quoting rules.  Revised again, in case you need it.

Thanks!

Nalin
From 837575de789228428618e1338256321769720abb Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:31:12 -0400
Subject: [PATCH 2/3] - create a cn=computers compat area populated with
 ieee802Device entries corresponding to computers with
 fqdn and macAddress attributes

---
 install/share/schema_compat.uldif   |   14 ++
 install/updates/10-schema_compat.update |   15 +++
 2 files changed, 29 insertions(+)

diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index f042edf..deca1bb 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -92,6 +92,20 @@ add:schema-compat-entry-attribute: 
'sudoRunAsGroup=%{ipaSudoRunAsExtGroup}'
 add:schema-compat-entry-attribute: 'sudoRunAsGroup=%deref(ipaSudoRunAs,cn)'
 add:schema-compat-entry-attribute: 'sudoOption=%{ipaSudoOpt}'
 
+dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config
+default:objectClass: top
+default:objectClass: extensibleObject
+default:cn: computers
+default:schema-compat-container-group: cn=compat, $SUFFIX
+default:schema-compat-container-rdn: cn=computers
+default:schema-compat-search-base: cn=computers, cn=accounts, $SUFFIX
+default:schema-compat-search-filter: 
((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:schema-compat-entry-rdn: cn=%first(%{fqdn})
+default:schema-compat-entry-attribute: objectclass=device
+default:schema-compat-entry-attribute: objectclass=ieee802Device
+default:schema-compat-entry-attribute: cn=%{fqdn}
+default:schema-compat-entry-attribute: macAddress=%{macAddress}
+
 # Enable anonymous VLV browsing for Solaris
 dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config
 only:aci: '(targetattr !=aci)(version 3.0; acl VLV Request Control; allow 
(read, search, compare, proxy) userdn = ldap:///anyone;; )'
diff --git a/install/updates/10-schema_compat.update 
b/install/updates/10-schema_compat.update
index 8ef1424..9835bb8 100644
--- a/install/updates/10-schema_compat.update
+++ b/install/updates/10-schema_compat.update
@@ -4,3 +4,18 @@ replace: 
schema-compat-entry-attribute:'sudoRunAsGroup=%deref(ipaSudoRunAs,cn
 # as the original, '' or -.
 dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config
 replace: 
schema-compat-entry-attribute:'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})::nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),%ifeq(\hostCategory\,\all\,\\,\-\),,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),%ifeq(\userCategory\,\all\,\\,\-\)),%{nisDomainName:-})'
+
+dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config
+default:objectClass: top
+default:objectClass: extensibleObject
+default:cn: computers
+default:schema-compat-container-group: cn=compat, $SUFFIX
+default:schema-compat-container-rdn: cn=computers
+default:schema-compat-search-base: cn=computers, cn=accounts, $SUFFIX
+default:schema-compat-search-filter: 
((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:schema-compat-entry-rdn: cn=%first(%{fqdn})
+default:schema-compat-entry-attribute: objectclass=device
+default:schema-compat-entry-attribute: objectclass=ieee802Device
+default:schema-compat-entry-attribute: cn=%{fqdn}
+default:schema-compat-entry-attribute: macAddress=%{macAddress}
+
-- 
1.7.10

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

Re: [Freeipa-devel] [PATCH] add ethers.byname and ethers.byaddr NIS maps

[Nalin Dahyabhai]

On Tue, Apr 24, 2012 at 01:02:44PM +0200, Jan Cholasta wrote:
 I'm just curious, why you do this:
 
 default:nis-keys-format: %mregsub(%{macAddress}
 %{fqdn},(..[:\\\|-]..[:\\\|-]..[:\\\|-]..[:\\\|-]..[:\\\|-]..)
 (.*),%1)
 
 and not simply this:
 
 default:nis-keys-format: ${macAddress}
 
 ?

Good eye.  It's because of an implementation detail of the server
plugin: when computing entries for a NIS map, it has to be able to deal
with the list of keys which it computes having a different number of
items in it than the list of corresponding values.

If an entry has, say, two 'fqdn' values, and three 'macAddress' values,
then for keys %{macAddress} would produce three values, and for
values, %{fqdn} %{macAddress} would produce six, since it's generating
all of the combinations.

In that case the plugin, assuming you want to make all six values
visible to clients, has to figure out how to match up three keys to six
values.  It can repeat the list of keys as the second (or rightmost)
variable changes, like this:
  key=fqdn1, value=macAddress1 fqdn1
  key=fqdn2, value=macAddress1 fqdn2
  key=fqdn3, value=macAddress1 fqdn3
  key=fqdn1, value=macAddress2 fqdn1
  key=fqdn2, value=macAddress2 fqdn2
  key=fqdn3, value=macAddress2 fqdn3
or it can repeat the list of keys as the first (or leftmost) variable
changes, like this:
  key=fqdn1, value=macAddress1 fqdn1
  key=fqdn2, value=macAddress2 fqdn1
  key=fqdn3, value=macAddress1 fqdn2
  key=fqdn1, value=macAddress2 fqdn2
  key=fqdn2, value=macAddress1 fqdn3
  key=fqdn3, value=macAddress2 fqdn3
Now, if your key is the second column, that's not what you want.  If
it's the first column, the second way actually looks right:
  key=macAddress1, value=macAddress1 fqdn1
  key=macAddress2, value=macAddress2 fqdn1
  key=macAddress1, value=macAddress1 fqdn2
  key=macAddress2, value=macAddress2 fqdn2
  key=macAddress1, value=macAddress1 fqdn3
  key=macAddress2, value=macAddress2 fqdn3

The plugin's not smart enough to figure out which way is correct (and at
the moment I can't even remember which way I ended up choosing), so the
configuration just makes sure that the list of keys starts out at the
same length as the list of values, and then uses the regex to strip out
the parts we don't want.

Revised patch attached.

Cheers,

Nalin
From 33aea09a1c1b48d6dcc3deef884fd33c938a1d6f Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:33:42 -0400
Subject: [PATCH 3/3] - add a pair of ethers maps for computers with hardware
 addresses on file

---
 install/share/nis.uldif   |   23 +++
 install/updates/50-nis.update |   23 +++
 2 files changed, 46 insertions(+)

diff --git a/install/share/nis.uldif b/install/share/nis.uldif
index 2255541..1e54828 100644
--- a/install/share/nis.uldif
+++ b/install/share/nis.uldif
@@ -70,3 +70,26 @@ default:nis-filter: (objectClass=ipanisNetgroup)
 default:nis-key-format: %{cn}
 default:nis-value-format:%merge( 
,%deref_f(\member\,\(objectclass=ipanisNetgroup)\,\cn\),(%link(\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\\\)\,\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\-\\\)\,\,\,\%ifeq(\\\userCategory\\\,\\\all\\\,\\,\\\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\\\)\,\%ifeq(\\\userCategory\\\,\\\all\\\,\\,\\\-\\\)\),%{nisDomainName:-}))
 default:nis-secure: no
+
+dn: nis-domain=$DOMAIN+nis-map=ethers.byaddr, cn=NIS Server, cn=plugins, 
cn=config
+default:objectclass: top
+default:objectclass: extensibleObject
+default:nis-domain: $DOMAIN
+default:nis-map: ethers.byaddr
+default:nis-base: cn=computers, cn=accounts, $SUFFIX
+default:nis-filter: ((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:nis-keys-format: %mregsub(%{macAddress} 
%{fqdn},(..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..) 
(.*),%1:%2:%3:%4:%5:%6)
+default:nis-values-format: %mregsub(%{macAddress} 
%{fqdn},(..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..) 
(.*),%1:%2:%3:%4:%5:%6 %7)
+default:nis-secure: no
+
+dn: nis-domain=$DOMAIN+nis-map=ethers.byname, cn=NIS Server, cn=plugins, 
cn=config
+default:objectclass: top
+default:objectclass: extensibleObject
+default:nis-domain: $DOMAIN
+default:nis-map: ethers.byname
+default:nis-base: cn=computers, cn=accounts, $SUFFIX
+default:nis-filter: ((macAddress=*)(fqdn

Re: [Freeipa-devel] [PATCH] compat ieee802Device entries for ipaHost entries

[Nalin Dahyabhai]

On Mon, Apr 23, 2012 at 05:03:28PM +0200, Jan Cholasta wrote:
 On 16.4.2012 22:39, Nalin Dahyabhai wrote:
 This bit of configuration creates a cn=computers area under cn=compat
 which we populate with ieee802Device entries corresponding to any
 ipaHost entries which have both fqdn and macAddress values.
 
 Please add this to install/updates/10-schema_compat.update as well.

Okay, I think a simple copy is enough, but am not yet sufficiently
familiar with the install/{share,update} stuff to be completely sure.

Nalin
From 9cfbef42a0efa8898caf3454c07b729f58f526ba Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:31:12 -0400
Subject: [PATCH 2/3] - create a cn=computers compat area populated with
 ieee802Device entries corresponding to computers with
 fqdn and macAddress attributes

---
 install/share/schema_compat.uldif   |   14 ++
 install/updates/10-schema_compat.update |   15 +++
 2 files changed, 29 insertions(+)

diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index f042edf..38bf678 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -92,6 +92,20 @@ add:schema-compat-entry-attribute: 
'sudoRunAsGroup=%{ipaSudoRunAsExtGroup}'
 add:schema-compat-entry-attribute: 'sudoRunAsGroup=%deref(ipaSudoRunAs,cn)'
 add:schema-compat-entry-attribute: 'sudoOption=%{ipaSudoOpt}'
 
+dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config
+default:objectClass: top
+default:objectClass: extensibleObject
+default:cn: computers
+default:schema-compat-container-group: cn=compat, $SUFFIX
+default:schema-compat-container-rdn: cn=computers
+default:schema-compat-search-base: cn=computers, cn=accounts, $SUFFIX
+default:schema-compat-search-filter: 
((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:schema-compat-entry-rdn: 'cn=%first(%{fqdn})'
+default:schema-compat-entry-attribute: objectclass=device
+default:schema-compat-entry-attribute: objectclass=ieee802Device
+default:schema-compat-entry-attribute: cn=%{fqdn}
+default:schema-compat-entry-attribute: macAddress=%{macAddress}
+
 # Enable anonymous VLV browsing for Solaris
 dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config
 only:aci: '(targetattr !=aci)(version 3.0; acl VLV Request Control; allow 
(read, search, compare, proxy) userdn = ldap:///anyone;; )'
diff --git a/install/updates/10-schema_compat.update 
b/install/updates/10-schema_compat.update
index 8ef1424..46a94c3 100644
--- a/install/updates/10-schema_compat.update
+++ b/install/updates/10-schema_compat.update
@@ -4,3 +4,18 @@ replace: 
schema-compat-entry-attribute:'sudoRunAsGroup=%deref(ipaSudoRunAs,cn
 # as the original, '' or -.
 dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config
 replace: 
schema-compat-entry-attribute:'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})::nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),%ifeq(\hostCategory\,\all\,\\,\-\),,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),%ifeq(\userCategory\,\all\,\\,\-\)),%{nisDomainName:-})'
+
+dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config
+default:objectClass: top
+default:objectClass: extensibleObject
+default:cn: computers
+default:schema-compat-container-group: cn=compat, $SUFFIX
+default:schema-compat-container-rdn: cn=computers
+default:schema-compat-search-base: cn=computers, cn=accounts, $SUFFIX
+default:schema-compat-search-filter: 
((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:schema-compat-entry-rdn: 'cn=%first(%{fqdn})'
+default:schema-compat-entry-attribute: objectclass=device
+default:schema-compat-entry-attribute: objectclass=ieee802Device
+default:schema-compat-entry-attribute: cn=%{fqdn}
+default:schema-compat-entry-attribute: macAddress=%{macAddress}
+
-- 
1.7.10

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

Re: [Freeipa-devel] [PATCH] index fqdn and macAddress attributes

[Nalin Dahyabhai]

On Mon, Apr 23, 2012 at 04:40:11PM +0200, Jan Cholasta wrote:
 On 16.4.2012 22:32, Nalin Dahyabhai wrote:
 When we implement ticket #2259, indexing fqdn and macAddress should help
 the Schema Compatibility and NIS Server plugins locate relevant computer
 entries more easily.
 
 Please add the indices to install/share/indices.ldif as well.

It's a bit of guesswork, but this should match the rest of the contents
of that file.

Nalin
From 3cdb82a3746931a0f566503c84c474909446de12 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:26:50 -0400
Subject: [PATCH 1/3] - index the fqdn and macAddress attributes for the sake
 of the compat plugin

---
 install/share/indices.ldif|   19 +++
 install/updates/20-indices.update |   16 
 2 files changed, 35 insertions(+)

diff --git a/install/share/indices.ldif b/install/share/indices.ldif
index 05c2765..6233d71 100644
--- a/install/share/indices.ldif
+++ b/install/share/indices.ldif
@@ -91,3 +91,22 @@ dn: cn=ntUserDomainId,cn=index,cn=userRoot,cn=ldbm 
database,cn=plugins,cn=config
 changetype: modify
 replace: nsIndexType
 nsIndexType: eq,pres
+
+dn: cn=fqdn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
+changetype: add
+ObjectClass: top
+ObjectClass: nsIndex
+cn: fqdn
+nsSystemIndex: false
+nsIndexType: eq
+nsIndexType: pres
+
+dn: cn=macAddress,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
+changetype: add
+ObjectClass: top
+ObjectClass: nsIndex
+cn: macAddress
+nsSystemIndex: false
+nsIndexType: eq
+nsIndexType: pres
+
diff --git a/install/updates/20-indices.update 
b/install/updates/20-indices.update
index b0e2f36..ecca027 100644
--- a/install/updates/20-indices.update
+++ b/install/updates/20-indices.update
@@ -32,3 +32,19 @@ default:ObjectClass: top
 default:ObjectClass: nsIndex
 default:nsSystemIndex: false
 default:nsIndexType: eq
+
+dn: cn=fqdn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
+default:cn: fqdn
+default:ObjectClass: top
+default:ObjectClass: nsIndex
+default:nsSystemIndex: false
+default:nsIndexType: eq
+default:nsIndexType: pres
+
+dn: cn=macAddress,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
+default:cn: macAddress
+default:ObjectClass: top
+default:ObjectClass: nsIndex
+default:nsSystemIndex: false
+default:nsIndexType: eq
+default:nsIndexType: pres
-- 
1.7.10

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

Re: [Freeipa-devel] [PATCH] add ethers.byname and ethers.byaddr NIS maps

[Nalin Dahyabhai]

On Mon, Apr 23, 2012 at 05:40:27PM +0200, Jan Cholasta wrote:
 On 23.4.2012 17:21, Jan Cholasta wrote:
 On 16.4.2012 22:51, Nalin Dahyabhai wrote:
 The ethers.byname and ethers.byaddr NIS maps pair host names and
 hardware network addresses. This should close ticket #2259.
 
 Please add this to install/updates/50-nis.update as well.
 
 Besides that, ACK on all 3 patches. I have checked only if ypcat and
 ypmatch work as expected, I would prefer if someone with more LDAP/NIS
 knowledge took a look at the patches before pushing them.
 
 I have just noticed one issue: we allow the octets in MAC addresses
 to be separated not only by :, but also by |, \ or -. Your
 patch doesn't seem to work for MAC addresses not using : as a
 separator:
 
 $ ipa host-mod host.example.com --macaddress 00:11:22:33:44:55
 
 $ ypcat ethers
 00:11:22:33:44:55 host.example.com
 
 $ ipa host-mod host.example.com --macaddress 00-11-22-33-44-55
 
 $ ypcat ethers
 nothing

Updated patch attached, but I'm skeptical that software which consumes
this data will handle anything other than ':', as neither RFC 2307 nor
ethers(5) mention it.  For that reason I'd lean toward either not
accepting data in that format, or fixing it up on its way in to the
directory -- we can fix it up when the compat plugins are computing the
data they'll serve (and I can revise the patch to configure them to do
so), but software that looks at the non-compat data won't benefit from
it.

Nalin
From 7bb76d236db9b9c0ed5b2c8faf959dc34a399a7c Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:33:42 -0400
Subject: [PATCH 3/3] - add a pair of ethers maps for computers with hardware
 addresses on file

---
 install/share/nis.uldif   |   23 +++
 install/updates/50-nis.update |   23 +++
 2 files changed, 46 insertions(+)

diff --git a/install/share/nis.uldif b/install/share/nis.uldif
index 2255541..f9747d5 100644
--- a/install/share/nis.uldif
+++ b/install/share/nis.uldif
@@ -70,3 +70,26 @@ default:nis-filter: (objectClass=ipanisNetgroup)
 default:nis-key-format: %{cn}
 default:nis-value-format:%merge( 
,%deref_f(\member\,\(objectclass=ipanisNetgroup)\,\cn\),(%link(\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\\\)\,\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\-\\\)\,\,\,\%ifeq(\\\userCategory\\\,\\\all\\\,\\,\\\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\\\)\,\%ifeq(\\\userCategory\\\,\\\all\\\,\\,\\\-\\\)\),%{nisDomainName:-}))
 default:nis-secure: no
+
+dn: nis-domain=$DOMAIN+nis-map=ethers.byaddr, cn=NIS Server, cn=plugins, 
cn=config
+default:objectclass: top
+default:objectclass: extensibleObject
+default:nis-domain: $DOMAIN
+default:nis-map: ethers.byaddr
+default:nis-base: cn=computers, cn=accounts, $SUFFIX
+default:nis-filter: ((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:nis-keys-format: %mregsub(%{macAddress} 
%{fqdn},(..[:\\\|-]..[:\\\|-]..[:\\\|-]..[:\\\|-]..[:\\\|-]..) (.*),%1)
+default:nis-values-format: %{macAddress} %{fqdn}
+default:nis-secure: no
+
+dn: nis-domain=$DOMAIN+nis-map=ethers.byname, cn=NIS Server, cn=plugins, 
cn=config
+default:objectclass: top
+default:objectclass: extensibleObject
+default:nis-domain: $DOMAIN
+default:nis-map: ethers.byname
+default:nis-base: cn=computers, cn=accounts, $SUFFIX
+default:nis-filter: ((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:nis-keys-format: %mregsub(%{macAddress} 
%{fqdn},(..[:\\\|-]..[:\\\|-]..[:\\\|-]..[:\\\|-]..[:\\\|-]..) (.*),%2)
+default:nis-values-format: %{macAddress} %{fqdn}
+default:nis-secure: no
+
diff --git a/install/updates/50-nis.update b/install/updates/50-nis.update
index 5c72639..6c1ca15 100644
--- a/install/updates/50-nis.update
+++ b/install/updates/50-nis.update
@@ -12,3 +12,26 @@ replace:nis-value-format: '%merge( 
,%{memberNisNetgroup},(%link(\%ifeq(\\\
 # https://bugzilla.redhat.com/show_bug.cgi?id=767372
 dn: nis-domain=$DOMAIN+nis-map=netgroup, cn=NIS Server, cn=plugins, cn=config
 replace:nis-value-format: '%merge( 
,%deref_f(\member\,\(objectclass=ipanisNetgroup)\,\cn\),(%link(\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member

[Freeipa-devel] [PATCH] index fqdn and macAddress attributes

[Nalin Dahyabhai]

When we implement ticket #2259, indexing fqdn and macAddress should help
the Schema Compatibility and NIS Server plugins locate relevant computer
entries more easily.

Nalin
From 44491a90ae258e3932a7a19d61313d28f8936978 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:26:50 -0400
Subject: [PATCH 1/3] - index the fqdn and macAddress attributes for the sake
 of the compat plugin

---
 install/updates/20-indices.update |   16 
 1 file changed, 16 insertions(+)

diff --git a/install/updates/20-indices.update 
b/install/updates/20-indices.update
index b0e2f36..ecca027 100644
--- a/install/updates/20-indices.update
+++ b/install/updates/20-indices.update
@@ -32,3 +32,19 @@ default:ObjectClass: top
 default:ObjectClass: nsIndex
 default:nsSystemIndex: false
 default:nsIndexType: eq
+
+dn: cn=fqdn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
+default:cn: fqdn
+default:ObjectClass: top
+default:ObjectClass: nsIndex
+default:nsSystemIndex: false
+default:nsIndexType: eq
+default:nsIndexType: pres
+
+dn: cn=macAddress,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
+default:cn: macAddress
+default:ObjectClass: top
+default:ObjectClass: nsIndex
+default:nsSystemIndex: false
+default:nsIndexType: eq
+default:nsIndexType: pres
-- 
1.7.10

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

[Freeipa-devel] [PATCH] compat ieee802Device entries for ipaHost entries

[Nalin Dahyabhai]

This bit of configuration creates a cn=computers area under cn=compat
which we populate with ieee802Device entries corresponding to any
ipaHost entries which have both fqdn and macAddress values.

Nalin
From 7cffe5a5d62e54e1dc7c621df131f621e49c14f5 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:31:12 -0400
Subject: [PATCH 2/3] - create a cn=computers compat area populated with
 ieee802Device entries corresponding to computers with
 fqdn and macAddress attributes

---
 install/share/schema_compat.uldif |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index f042edf..38bf678 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -92,6 +92,20 @@ add:schema-compat-entry-attribute: 
'sudoRunAsGroup=%{ipaSudoRunAsExtGroup}'
 add:schema-compat-entry-attribute: 'sudoRunAsGroup=%deref(ipaSudoRunAs,cn)'
 add:schema-compat-entry-attribute: 'sudoOption=%{ipaSudoOpt}'
 
+dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config
+default:objectClass: top
+default:objectClass: extensibleObject
+default:cn: computers
+default:schema-compat-container-group: cn=compat, $SUFFIX
+default:schema-compat-container-rdn: cn=computers
+default:schema-compat-search-base: cn=computers, cn=accounts, $SUFFIX
+default:schema-compat-search-filter: 
((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:schema-compat-entry-rdn: 'cn=%first(%{fqdn})'
+default:schema-compat-entry-attribute: objectclass=device
+default:schema-compat-entry-attribute: objectclass=ieee802Device
+default:schema-compat-entry-attribute: cn=%{fqdn}
+default:schema-compat-entry-attribute: macAddress=%{macAddress}
+
 # Enable anonymous VLV browsing for Solaris
 dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config
 only:aci: '(targetattr !=aci)(version 3.0; acl VLV Request Control; allow 
(read, search, compare, proxy) userdn = ldap:///anyone;; )'
-- 
1.7.10

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

[Freeipa-devel] [PATCH] add ethers.byname and ethers.byaddr NIS maps

[Nalin Dahyabhai]

The ethers.byname and ethers.byaddr NIS maps pair host names and
hardware network addresses.  This should close ticket #2259.

Nalin
From a69406b83496c053dbe68ab7e019c86242c06565 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Mon, 16 Apr 2012 15:33:42 -0400
Subject: [PATCH 3/3] - add a pair of ethers maps for computers with hardware
 addresses on file

---
 install/share/nis.uldif |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/install/share/nis.uldif b/install/share/nis.uldif
index 2255541..96b790f 100644
--- a/install/share/nis.uldif
+++ b/install/share/nis.uldif
@@ -70,3 +70,26 @@ default:nis-filter: (objectClass=ipanisNetgroup)
 default:nis-key-format: %{cn}
 default:nis-value-format:%merge( 
,%deref_f(\member\,\(objectclass=ipanisNetgroup)\,\cn\),(%link(\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\\\)\,\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\-\\\)\,\,\,\%ifeq(\\\userCategory\\\,\\\all\\\,\\,\\\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\\\)\,\%ifeq(\\\userCategory\\\,\\\all\\\,\\,\\\-\\\)\),%{nisDomainName:-}))
 default:nis-secure: no
+
+dn: nis-domain=$DOMAIN+nis-map=ethers.byaddr, cn=NIS Server, cn=plugins, 
cn=config
+default:objectclass: top
+default:objectclass: extensibleObject
+default:nis-domain: $DOMAIN
+default:nis-map: ethers.byaddr
+default:nis-base: cn=computers, cn=accounts, $SUFFIX
+default:nis-filter: ((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:nis-keys-format: %mregsub(%{macAddress} %{fqdn},(..:..:..:..:..:..) 
(.*),%1)
+default:nis-values-format: %{macAddress} %{fqdn}
+default:nis-secure: no
+
+dn: nis-domain=$DOMAIN+nis-map=ethers.byname, cn=NIS Server, cn=plugins, 
cn=config
+default:objectclass: top
+default:objectclass: extensibleObject
+default:nis-domain: $DOMAIN
+default:nis-map: ethers.byname
+default:nis-base: cn=computers, cn=accounts, $SUFFIX
+default:nis-filter: ((macAddress=*)(fqdn=*)(objectClass=ipaHost))
+default:nis-keys-format: %mregsub(%{macAddress} %{fqdn},(..:..:..:..:..:..) 
(.*),%2)
+default:nis-values-format: %{macAddress} %{fqdn}
+default:nis-secure: no
+
-- 
1.7.10

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

Re: [Freeipa-devel] [PATCH] 998 certmonger restarts services on renewal

[Nalin Dahyabhai]

On Mon, Apr 02, 2012 at 03:47:20PM +0200, Martin Kosek wrote:
 On Tue, 2012-03-27 at 17:40 -0400, Rob Crittenden wrote:
  Certmonger will currently automatically renew server certificates but 
  doesn't restart the services so you can still end up with expired 
  certificates if you services never restart.
  
  This patch registers are restart command with certmonger so the IPA 
  services will automatically be restarted to get the updated cert.
  
  Easy to test. Install IPA then resubmit the current server certs and 
  watch the services restart:
  
  # ipa-getcert list
  
  Find the ID for either your dirsrv or httpd instance
  
  # ipa-getcert resubmit -i ID
  
  Watch /var/log/httpd/error_log or /var/log/dirsrv/slapd-INSTANCE/errors 
  to see the service restart.
 
 What about current instances - can we/do we want to update certmonger
 tracking so that their instances are restarted as well?

You can use the not-exactly-well-named start-tracking command to add a
post-save command:

  ipa-getcert start-tracking \
-d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert \
-C /usr/bin/logger BeenThereDoneThat

Or use the ID, as Rob did above.

HTH,

Nalin

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

Re: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with Failed password error

[Nalin Dahyabhai]

On Fri, Mar 09, 2012 at 04:06:33PM -0500, Dmitri Pal wrote:
As far as I understand underlying DS can also be configured to create
weak hashes needed for NIS but it is not recommended. But this is
something that gurus should confirm.

The NIS server will serve up password hashes which are compatible with
traditional crypt() if any are found in an entry's userPassword
attribute.  By default, the directory server doesn't create them in this
form (it prefers SSHA, or SSHA256, I guess), but this can be changed by
setting passwordStorageScheme: CRYPT in its cn=config entry.

Two things to watch out for, though.

The first is that when you make the change, the directory server starts
generating userPassword values which begin with {crypt}, but the
default configuration for the NIS server told it to look for values
which began with {CRYPT}, in a case-sensitive manner, so it wouldn't
match them.  This was corrected in slapi-nis 0.29.  You'll want to
either grab a newer package to pick up the new defaults, or override the
run-time configuration of your copy to match the defaults from later
versions.

The second is that changing your passwordStorageScheme only affects how
the server hashes passwords that will be set after you make the change,
so if you're going to do it, it's better done sooner rather than later.

HTH,

Nalin

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

Re: [Freeipa-devel] [PATCH] 913 Fix pylint failures on F-16

[Nalin Dahyabhai]

On Thu, Dec 08, 2011 at 04:14:38PM -0500, Rob Crittenden wrote:
 A few things need to be updated to make the ipa-2-1 branch build in
 F-16 with pylint.
 
 I've updated the example to use the object's default_attribute list
 instead of using output_params(), this is preferred anyway
 
 I also replaced a few instances of add_s() with addEntry()

Ack: pylint is happy on my F-17 box.

Nalin

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

Re: [Freeipa-devel] [PATCH] #2038 modify salt creation

[Nalin Dahyabhai]

On Thu, Nov 03, 2011 at 06:26:15PM -0400, Simo Sorce wrote:
 As stated in the bug in order to attain better interoperability with
 Windows clients we need to change the way we generate the random salt.

Nack.  The data in a krb5_data is of type 'char', and if it's signed,
the math used here doesn't produce a printable result.  Might also want
to increase KRB5P_SALT_SIZE.

Nalin

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

Re: [Freeipa-devel] [PATCH] #2038 modify salt creation

[Nalin Dahyabhai]

On Fri, Nov 04, 2011 at 04:45:02PM -0400, Simo Sorce wrote:
 After a quick review with nalin offline I decided for a different
 approach that properly covers the range of values we want and is more
 similar to the initial code.
 
 New patches attached.

Looks good to me.  Please bump up KRB5P_SALT_SIZE, say, to 20, unless
there's a good reason not to, though.

Either way, ACK.

Nalin

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

Re: [Freeipa-devel] change to interface used to provide certificates

[Nalin Dahyabhai]

On Fri, Oct 14, 2011 at 11:23:27PM -0400, John Dennis wrote:
 Importing and exporting certs via the web UI and command line are
 not common operations. The only significant impact changing to
 requiring PEM input would be on our automated tests which would have
 to make sure they supplied PEM format.
 
 Comments? Questions?

If we're talking about the cert_request RPC, then this impacts
certmonger, so I need to know (and would prefer to know sooner rather
than later) if it needs to change its expectations.

Cheers,

Nalin

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

[Freeipa-devel] [PATCH] tweaks to ipa-replica-prepare.1

[Nalin Dahyabhai]

I started reading this page, and the description for --pkinit_pin looked
wrong.  While in there, I figured it might be useful to note that the
PKCS#12 files also contain the private keys.

Nalin
From 8fe270e43d7790dbd4210be9ff212ce410e3da69 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Tue, 4 Oct 2011 18:29:45 -0400
Subject: [PATCH 2/2] - note that PKCS#12 files also contain private keys, and
 that the pkinit options refer to the KDC's
 credentials

---
 install/tools/man/ipa-replica-prepare.1 |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/install/tools/man/ipa-replica-prepare.1 
b/install/tools/man/ipa-replica-prepare.1
index c9cd544..7443483 100644
--- a/install/tools/man/ipa-replica-prepare.1
+++ b/install/tools/man/ipa-replica-prepare.1
@@ -34,10 +34,13 @@ Once the file has been created it will be named 
replica\-hostname. This file can
 .SH OPTIONS
 .TP
 \fB\-\-dirsrv_pkcs12\fR=\fIFILE\fR
-PKCS#12 file containing the Directory Server SSL Certificate
+PKCS#12 file containing the Directory Server SSL Certificate and Private Key
 .TP
 \fB\-\-http_pkcs12\fR=\fIFILE\fR
-PKCS#12 file containing the Apache Server SSL Certificate
+PKCS#12 file containing the Apache Server SSL Certificate and Private Key
+.TP
+\fB\-\-pkinit_pkcs12\fR=\fIFILE\fR
+PKCS#12 file containing the Kerberos KDC Certificate and Private Key
 .TP
 \fB\-\-dirsrv_pin\fR=\fIDIRSRV_PIN\fR
 The password of the Directory Server PKCS#12 file
@@ -46,7 +49,7 @@ The password of the Directory Server PKCS#12 file
 The password of the Apache Server PKCS#12 file
 .TP
 \fB\-\-pkinit_pin\fR=\fIPKINIT_PIN\fR
-The password of the Apache Server PKCS#12 file
+The password of the Kerberos KDC PKCS#12 file
 .TP
 \fB\-p\fR \fIDM_PASSWORD\fR, \fB\-\-password\fR=\fIDM_PASSWORD\fR
 Directory Manager (existing master) password
-- 
1.7.6.4

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

[Freeipa-devel] [PATCH] Select a server with a CA on it when submitting signing requests.

[Nalin Dahyabhai]

This is a stab at fixing #1252 - teaching the RA to handle cases where
the local server isn't a CA.

When the RA is about to submit a signing request to a CA, it currently
assumes that the CA is colocated.  This modifies its behavior so that
the first time it needs to submit a signing request, it:

 1. Checks if the configured ca_host is actually a CA.  If it is, use it.
 2. Checks if the local host (if it's not also the configured ca_host)
is a CA.  If it is, use it.
 3. Checks if there are any CAs in the domain.  If there are, select one
of them at random and use it.
 4. Give up, behave as before, and let the error we previously would
have gotten for trying to submit a signing request to a non-CA happen.

Nalin
From 373fd1a878f39361a33c58e7ccf6057159d203be Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@dahyabhai.net
Date: Wed, 8 Jun 2011 11:09:28 -0400
Subject: [PATCH] Select a server with a CA on it when submitting signing
 requests.

When the RA is about to submit a signing request to a CA, check
if the ca_host is actually a CA.  If it isn't, and it isn't the
local host, check if the local host is a CA.  If that doesn't
work, try to select a CA host at random.  If there aren't any,
just give up and pretend the ca_host is a CA so that we can fail
to connect to it, as we would have before.  Ticket #1252.
---
 ipaserver/plugins/dogtag.py |   68 +--
 1 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py
index 8563848..d1234a0 100644
--- a/ipaserver/plugins/dogtag.py
+++ b/ipaserver/plugins/dogtag.py
@@ -1196,7 +1196,7 @@ from ipalib import api, SkipPluginModule
 if api.env.ra_plugin != 'dogtag':
 # In this case, abort loading this plugin module...
 raise SkipPluginModule(reason='dogtag not selected as RA plugin')
-import os
+import os, random, ldap
 from ipaserver.plugins import rabase
 from ipalib.errors import NetworkError, CertificateOperationError
 from ipalib.constants import TYPE_ERROR
@@ -1218,6 +1218,7 @@ class ra(rabase.rabase):
 self.ipa_key_size = 2048
 self.ipa_certificate_nickname = ipaCert
 self.ca_certificate_nickname = caCert
+self.ca_host = None
 try:
 f = open(self.pwd_file, r)
 self.password = f.readline().strip()
@@ -1226,6 +1227,63 @@ class ra(rabase.rabase):
 self.password = ''
 super(ra, self).__init__()
 
+def _host_has_service(self, host, service='CA'):
+
+:param host: A host which might be a master for a service.
+:param service: The service for which the host might be a master.
+:return:   (true, false)
+
+Check if a specified host is a master for a specified service.
+
+base_dn = 'cn=%s,cn=masters,cn=ipa,cn=etc,%s' % (host, api.env.basedn)
+filter = 
'((objectClass=ipaConfigObject)(cn=%s)(ipaConfigString=enabledService))' % 
service
+try:
+ldap2 = self.api.Backend.ldap2
+ent,trunc = ldap2.find_entries(filter=filter, base_dn=base_dn)
+if len(ent):
+return True
+except Exception, e:
+pass
+return False
+
+def _select_any_master(self, service='CA'):
+
+:param service: The service for which we're looking for a master.
+:return:   host
+   as str
+
+Select any host which is a master for a specified service.
+
+base_dn = 'cn=masters,cn=ipa,cn=etc,%s' % api.env.basedn
+filter = 
'((objectClass=ipaConfigObject)(cn=%s)(ipaConfigString=enabledService))' % 
service
+try:
+ldap2 = self.api.Backend.ldap2
+ent,trunc = ldap2.find_entries(filter=filter, base_dn=base_dn)
+if len(ent):
+entry = random.choice(ent)
+return ldap.explode_dn(dn=entry[0],notypes=True)[1]
+except Exception, e:
+pass
+return None
+
+def _select_ca(self):
+
+:return:   host
+   as str
+
+Select our CA host.
+
+if self._host_has_service(host=api.env.ca_host):
+return api.env.ca_host
+if api.env.host != api.env.ca_host:
+if self._host_has_service(host=api.env.host):
+return api.env.host
+host = self._select_any_master()
+if host:
+return host
+else:
+return api.env.ca_host
+
 def _request(self, url, port, **kw):
 
 :param url: The URL to post to.
@@ -1235,7 +1293,9 @@ class ra(rabase.rabase):
 
 Perform an HTTP request.
 
-return dogtag.http_request(self.env.ca_host, port, url, **kw)
+if self.ca_host == None:
+self.ca_host = self._select_ca()
+return dogtag.http_request(self.ca_host, port, url, **kw)
 
 def _sslget(self, url, port, **kw

Re: [Freeipa-devel] Determine KDC for a website

[Nalin Dahyabhai]

On Thu, Mar 17, 2011 at 08:03:14PM -0400, Adam Young wrote:
 I'm trying to figure out what should happen in the following case;
 
 A user goes to a website that they've never visited before.
 The site is using Kerberos, and thus the browser gets back a
 Negotiate response.
 
 At this point, the browser chops the hostname off the URL and
 requests the TXT record for _kerberos.+domain
 This gives the browser back the REALM.

The client will only consult DNS here if dns_lookup_realm is enabled
in the [libdefaults] section of your krb5.conf.

If the client's KDC is capable of issuing referrals and knows that the
web server host is a member of a particular realm, then the client will
trust that its KDC is pointing it in the right direction, regardless of
what's in DNS.

 Now, there seems to be an understanding that the default REALM to
 domain mapping should be  REALM.to_lower.
 
 Now to find the KDC for the server, I can do a DNS query  for the
 SRV record
 
 _kerberos._udp. + domain.

Section 7.2.3 of rfc4120 describes this in more detail.

 However, when I have a krb5 conf setup that does not explicitly set
 the kdc value below
 
 [realms]
  AYOUNG.BOSTON.DEVEL.REDHAT.COM = {
   kdc = ipa14.ayoung.boston.devel.redhat.com:88
 }
 
 ...I cannot kinit against the realm AYOUNG.BOSTON.DEVEL.REDHAT.COM.
 I've confirmed that I can query my IPA server's DNS server and get
 the appropriate records.

 Is there a step I am missing, or is this lookup no supported in the
 library?  Is there some way I can better debug this?

Is your client configured to consult DNS in this way?  Specifically, is
dns_lookup_kdc enabled in the [libdefaults] section?

HTH,

Nalin

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

[Freeipa-devel] [PATCH] drop the group.upg NIS map

[Nalin Dahyabhai]

The group.upg NIS map was an experiment in providing UPG groups
dynamically, and is not one of the maps that I'd ever expect a NIS
client to know to search.  We should probably just drop it.

---
 install/share/nis.uldif |   12 
 1 files changed, 0 insertions(+), 12 deletions(-)

diff --git a/install/share/nis.uldif b/install/share/nis.uldif
index f23b49e..639c88a 100644
--- a/install/share/nis.uldif
+++ b/install/share/nis.uldif
@@ -45,18 +45,6 @@ default:nis-map: group.bygid
 default:nis-base: cn=groups, cn=accounts, $SUFFIX
 default:nis-secure: no
 
-dn: nis-domain=$DOMAIN+nis-map=group.upg, cn=NIS Server, cn=plugins, cn=config
-default:objectclass: top
-default:objectclass: extensibleObject
-default:nis-domain: $DOMAIN
-default:nis-map: group.upg
-default:nis-base: cn=users, cn=accounts, $SUFFIX
-default:nis-filter: (objectclass=posixAccount)
-default:nis-key-format: %{uid}
-default:nis-value-format: %{uid}:*:%{gidNumber}:%{uid}
-default:nis-secure: no
-default:nis-disallowed-chars: :,
-
 dn: nis-domain=$DOMAIN+nis-map=netid.byname, cn=NIS Server, cn=plugins, 
cn=config
 default:objectclass: top
 default:objectclass: extensibleObject
-- 
1.7.4

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

Re: [Freeipa-devel] Dropping support for Fedora 13

[Nalin Dahyabhai]

On Fri, Jan 14, 2011 at 08:00:40AM -0500, Stephen Gallagher wrote:
 Please leave the SSSD building for F13 for a while yet. We do have users
 playing with it there.

Ok.  Just ipa itself, then.

Nalin

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

Re: [Freeipa-devel] Dropping support for Fedora 13

[Nalin Dahyabhai]

On Wed, Jan 12, 2011 at 05:49:42PM -0500, Rob Crittenden wrote:
 With the patch titled '674 drop build dep on mozlap' freeipa v2 will
 no longer build on Fedora 13.

So just to be clear, we should stop trying to build git snapshot builds
on f13?  If so, is this for everything, just the freeipa package, or
something in between?

Nalin

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

Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

[Nalin Dahyabhai]

On Thu, Dec 09, 2010 at 02:59:55PM -0500, Dmitri Pal wrote:
 1) Adjust the compat plugin as described above

Attached for testing.  Patch 0001 we've seen before; 0002's new.

Nalin
From 1afcb4d6163f5b8137cb1f2e832714e046345ca7 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Tue, 30 Nov 2010 18:25:33 -0500
Subject: [PATCH 1/2] sudo and netgroup schema compat updates
 - fix quoting of netgroup entries
 - don't bother looking for members of netgroups by looking for entries
   which list memberOf: $netgroup -- the netgroup should list them as
   member values
 - use newer slapi-nis functionality to produce cn=sudoers
 - drop the real cn=sudoers container to make room for the compat
   container

---
 install/share/bootstrap-template.ldif |6 -
 install/share/schema_compat.uldif |   37 
 ipa.spec.in   |2 +-
 3 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/install/share/bootstrap-template.ldif 
b/install/share/bootstrap-template.ldif
index 4f10f07..81eb5d6 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -64,12 +64,6 @@ objectClass: top
 objectClass: nsContainer
 cn: sudorules
 
-dn: cn=SUDOers,$SUFFIX
-changetype: add
-objectClass: nsContainer
-objectClass: top
-cn: SUDOers
-
 dn: cn=etc,$SUFFIX
 changetype: add
 objectClass: nsContainer
diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index 22e3141..52c8d5a 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -47,7 +47,6 @@ default:schema-compat-entry-attribute: objectclass=posixGroup
 default:schema-compat-entry-attribute: gidNumber=%{gidNumber}
 default:schema-compat-entry-attribute: memberUid=%{memberUid}
 default:schema-compat-entry-attribute: memberUid=%deref(member,uid)
-default:schema-compat-entry-attribute: 
memberUid=%referred(cn=users,memberOf,uid)
 
 dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config
 add:objectClass: top
@@ -56,14 +55,42 @@ add:cn: ng
 add:schema-compat-container-group: 'cn=compat, $SUFFIX'
 add:schema-compat-container-rdn: cn=ng
 add:schema-compat-check-access: yes
-add:schema-compat-search-base: 'cn=ng,cn=alt,$SUFFIX'
-add:schema-compat-search-filter: !(cn=ng)
+add:schema-compat-search-base: 'cn=ng, cn=alt, $SUFFIX'
+add:schema-compat-search-filter: (objectclass=ipaNisNetgroup)
 add:schema-compat-entry-rdn: cn=%{cn}
 add:schema-compat-entry-attribute: objectclass=nisNetgroup
 add:schema-compat-entry-attribute: 'memberNisNetgroup=%deref_r(member,cn)'
-add:schema-compat-entry-attribute: 
'memberNisNetgroup=%referred_r(cn=ng,memberOf,cn)'
-add:schema-compat-entry-attribute: 
nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})
+add:schema-compat-entry-attribute: 
'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})'
+
+dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
+add:objectClass: top
+add:objectClass: extensibleObject
+add:cn: sudoers
+add:schema-compat-container-group: 'cn=SUDOers, $SUFFIX'
+add:schema-compat-search-base: 'cn=sudorules, $SUFFIX'
+add:schema-compat-search-filter: 
((objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))
+add:schema-compat-entry-rdn: cn=%{cn}
+add:schema-compat-entry-attribute: objectclass=sudoRole
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%{externalUser})'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%deref_f(\memberUser\,\(objectclass=posixAccount)\,\uid\))'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%deref_rf(\memberUser\,\((objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\,\member\,\(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\,\uid\))'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%%%deref_f(\memberUser\,\(objectclass=posixGroup)\,\cn\))'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,+%deref_f

Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

[Nalin Dahyabhai]

On Wed, Dec 08, 2010 at 11:12:34PM +, JR Aquino wrote:
 I guess the piece that is still missing then is:
 
 Instead of:
 
 sudoHost: hostname.com
 
 It should be:
 
 sudoHost: +production - which is the group assigned to the ipasudorule.

The memberHost cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com in
the rule is a hostgroup but not a netgroup, so I think it's doing the
right thing by resolving the group down to its members' names.

Nalin

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

[Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

[Nalin Dahyabhai]

This is what I've got now; I think it's correct.

 - fix quoting in the netgroup compat configuration entry
 - don't bother looking for members of netgroups by looking for entries
   which list memberOf: $netgroup -- the netgroup should list them as
   member or memberUser or memberHost values
 - use newer slapi-nis functionality to produce cn=sudoers
 - drop the real cn=sudoers container to make room for the compat
   container

Feel free to adjust the schema-compat-container-group for the
cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config entry -- the
location of the compat sudo entries is of no concern to me.

Cheers,

Nalin
From 9baefea23f5b944d244eed4bef3f85df3203ae45 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Tue, 30 Nov 2010 18:25:33 -0500
Subject: [PATCH] sudo and netgroup schema compat updates
 - fix quoting in the netgroup compat configuration entry
 - don't bother looking for members of netgroups by looking for entries
   which list memberOf: $netgroup -- the netgroup should list them as
   member or memberUser or memberHost values
 - use newer slapi-nis functionality to produce cn=sudoers
 - drop the real cn=sudoers container to make room for the compat
   container

---
 install/share/bootstrap-template.ldif |6 -
 install/share/schema_compat.uldif |   37 
 ipa.spec.in   |2 +-
 3 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/install/share/bootstrap-template.ldif 
b/install/share/bootstrap-template.ldif
index 7946526..283d226 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -64,12 +64,6 @@ objectClass: top
 objectClass: nsContainer
 cn: sudorules
 
-dn: cn=SUDOers,$SUFFIX
-changetype: add
-objectClass: nsContainer
-objectClass: top
-cn: SUDOers
-
 dn: cn=etc,$SUFFIX
 changetype: add
 objectClass: nsContainer
diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index 22e3141..52c8d5a 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -47,7 +47,6 @@ default:schema-compat-entry-attribute: objectclass=posixGroup
 default:schema-compat-entry-attribute: gidNumber=%{gidNumber}
 default:schema-compat-entry-attribute: memberUid=%{memberUid}
 default:schema-compat-entry-attribute: memberUid=%deref(member,uid)
-default:schema-compat-entry-attribute: 
memberUid=%referred(cn=users,memberOf,uid)
 
 dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config
 add:objectClass: top
@@ -56,14 +55,42 @@ add:cn: ng
 add:schema-compat-container-group: 'cn=compat, $SUFFIX'
 add:schema-compat-container-rdn: cn=ng
 add:schema-compat-check-access: yes
-add:schema-compat-search-base: 'cn=ng,cn=alt,$SUFFIX'
-add:schema-compat-search-filter: !(cn=ng)
+add:schema-compat-search-base: 'cn=ng, cn=alt, $SUFFIX'
+add:schema-compat-search-filter: (objectclass=ipaNisNetgroup)
 add:schema-compat-entry-rdn: cn=%{cn}
 add:schema-compat-entry-attribute: objectclass=nisNetgroup
 add:schema-compat-entry-attribute: 'memberNisNetgroup=%deref_r(member,cn)'
-add:schema-compat-entry-attribute: 
'memberNisNetgroup=%referred_r(cn=ng,memberOf,cn)'
-add:schema-compat-entry-attribute: 
nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})
+add:schema-compat-entry-attribute: 
'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})'
+
+dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
+add:objectClass: top
+add:objectClass: extensibleObject
+add:cn: sudoers
+add:schema-compat-container-group: 'cn=SUDOers, $SUFFIX'
+add:schema-compat-search-base: 'cn=sudorules, $SUFFIX'
+add:schema-compat-search-filter: 
((objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))
+add:schema-compat-entry-rdn: cn=%{cn}
+add:schema-compat-entry-attribute: objectclass=sudoRole
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%{externalUser})'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL

[Freeipa-devel] [PATCH] build tweaks

[Nalin Dahyabhai]

The attached patch modifies autogen.sh so that it runs autoreconf with
the -f flag, too, so that a source rpm package built on an F14 system
will successfully build on a system which has older autotools versions.

It also tells automake to run in its 'foreign' mode and dispenses with
some workarounds for when we were running it in 'gnu' mode.

Nalin
From 5bb5c58a0ac713069fbd44cb8b7906485648de13 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Wed, 24 Nov 2010 17:39:46 -0500
Subject: [PATCH] build tweaks
 - use automake's foreign mode, avoid creating empty files to satisfy gnu mode
 - run autoreconf -f to ensure that everything matches

---
 autogen.sh |   13 +
 contrib/RHEL4/configure.ac |2 +-
 daemons/configure.ac   |2 +-
 install/configure.ac   |2 +-
 ipa-client/configure.ac|2 +-
 ipa.spec.in|4 
 6 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index 99b4805..5eab4a4 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,14 +1,3 @@
 #!/bin/sh
-
-# automake demands these files exist when run in gnu mode which is the default,
-# automake can be run in foreign mode to avoid failing on the absence of these
-# files, but unfortunately there is no way to pass the --foreign flag to
-# automake when run from autoreconf.
-for f in NEWS README AUTHORS ChangeLog; do
-if [ ! -e $f ]; then
-touch $f
-fi
-done
-
-autoreconf -i
+autoreconf -i -f
 ./configure ${1+$@}
diff --git a/contrib/RHEL4/configure.ac b/contrib/RHEL4/configure.ac
index 83676a3..1fd3fd2 100644
--- a/contrib/RHEL4/configure.ac
+++ b/contrib/RHEL4/configure.ac
@@ -3,7 +3,7 @@ AC_INIT([ipa-client],
 [0.99.0],
 [http://www.freeipa.org/])
 
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([foreign])
 
 AC_SUBST(VERSION)
 
diff --git a/daemons/configure.ac b/daemons/configure.ac
index da86557..d959f98 100644
--- a/daemons/configure.ac
+++ b/daemons/configure.ac
@@ -6,7 +6,7 @@ AC_INIT([ipa-server],
 
 AC_CONFIG_HEADERS([config.h])
 
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([foreign])
 
 AM_MAINTAINER_MODE
 AC_PROG_CC
diff --git a/install/configure.ac b/install/configure.ac
index 5cdfb79..2424ef2 100644
--- a/install/configure.ac
+++ b/install/configure.ac
@@ -7,7 +7,7 @@ AC_INIT([ipa-server],
 #AC_CONFIG_SRCDIR([ipaserver/ipaldap.py])
 AC_CONFIG_HEADERS([config.h])
 
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([foreign])
 
 AM_MAINTAINER_MODE
 #AC_PROG_CC
diff --git a/ipa-client/configure.ac b/ipa-client/configure.ac
index 95becd3..75544ae 100644
--- a/ipa-client/configure.ac
+++ b/ipa-client/configure.ac
@@ -9,7 +9,7 @@ AC_PROG_LIBTOOL
 AC_CONFIG_SRCDIR([ipaclient/__init__.py])
 AC_CONFIG_HEADERS([config.h])
 
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([foreign])
 
 AM_MAINTAINER_MODE
 
diff --git a/ipa.spec.in b/ipa.spec.in
index b43aa8e..775c52e 100644
--- a/ipa.spec.in
+++ b/ipa.spec.in
@@ -223,10 +223,6 @@ administering radius authentication settings in IPA.
 export CFLAGS=$CFLAGS %{optflags}
 export CPPFLAGS=$CPPFLAGS %{optflags}
 make version-update
-%if ! %{ONLY_CLIENT}
-touch daemons/NEWS daemons/README daemons/AUTHORS daemons/ChangeLog
-touch install/NEWS install/README install/AUTHORS install/ChangeLog
-%endif
 cd ipa-client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} 
--localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd ..
 %if ! %{ONLY_CLIENT}
 cd daemons; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} 
--localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd ..
-- 
1.7.3.2

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

Re: [Freeipa-devel] Where we are with SUDO?

[Nalin Dahyabhai]

On Mon, Nov 22, 2010 at 07:18:42PM +, JR Aquino wrote:
 On 11/18/10 3:11 PM, Dmitri Pal d...@redhat.com wrote:
 JR Aquino wrote:
  The IPA SudoRule Structure has largely been based off of what we are
 doing
  today with HBAC.
 
  HBAC does not distinguish between memberGroup or memberNetgroup... Its
  simply, memberHost and memberUser for both HBAC and IPASudoRules.
 
  Also, when HBAC or IPASudoRules add a member, there is no resulting
  'memberOf' or (hbacMemberOf/sudoMemberOf) inserted into the usergroup,
  hostgroup, command group, etc...  Whereas, if you add a host to a
  hostgroup, the host ends up with a pointer referring back to the
  hostgroup.  I believe this was done to provide referential integrity.

No problem.  References to memberOf were there before mainly to try to
cover unusual cases, but they can be dropped so long as people aren't
going to go around adding memberOf values just for kicks.

 Nalin is working on a solution to this. We do not need to modify schema.
 Instead he is adding code to make checks on the object type and have a
 way to transform the value in different ways based on this check.
 
 Excellent!
 
 I'll retest as soon as the new patch is available!

Attached.  You'll need the current snapshot of slapi-nis in order to get
functionality that the new configuration patch depends on.

Cheers,

Nalin
From 96e6467b20c69051147ed1dc9d7023169cce7c7e Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Tue, 23 Nov 2010 15:38:40 -0500
Subject: [PATCH] - fix quoting of netgroup entries
 - use newer slapi-nis functionality to produce cn=sudoers
 - drop the real cn=sudoers container

---
 install/share/bootstrap-template.ldif |6 -
 install/share/schema_compat.uldif |   35 ++--
 ipa.spec.in   |2 +-
 3 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/install/share/bootstrap-template.ldif 
b/install/share/bootstrap-template.ldif
index 7946526..283d226 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -64,12 +64,6 @@ objectClass: top
 objectClass: nsContainer
 cn: sudorules
 
-dn: cn=SUDOers,$SUFFIX
-changetype: add
-objectClass: nsContainer
-objectClass: top
-cn: SUDOers
-
 dn: cn=etc,$SUFFIX
 changetype: add
 objectClass: nsContainer
diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index 22e3141..d74a9c0 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -56,14 +56,43 @@ add:cn: ng
 add:schema-compat-container-group: 'cn=compat, $SUFFIX'
 add:schema-compat-container-rdn: cn=ng
 add:schema-compat-check-access: yes
-add:schema-compat-search-base: 'cn=ng,cn=alt,$SUFFIX'
-add:schema-compat-search-filter: !(cn=ng)
+add:schema-compat-search-base: 'cn=ng, cn=alt, $SUFFIX'
+add:schema-compat-search-filter: (objectclass=ipaNisNetgroup)
 add:schema-compat-entry-rdn: cn=%{cn}
 add:schema-compat-entry-attribute: objectclass=nisNetgroup
 add:schema-compat-entry-attribute: 'memberNisNetgroup=%deref_r(member,cn)'
 add:schema-compat-entry-attribute: 
'memberNisNetgroup=%referred_r(cn=ng,memberOf,cn)'
-add:schema-compat-entry-attribute: 
nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})
+add:schema-compat-entry-attribute: 
'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})'
+
+dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
+add:objectClass: top
+add:objectClass: extensibleObject
+add:cn: sudoers
+add:schema-compat-container-group: 'cn=sudoers, $SUFFIX'
+add:schema-compat-search-base: 'cn=sudorules, $SUFFIX'
+add:schema-compat-search-filter: 
((objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))
+add:schema-compat-entry-rdn: cn=%{cn}
+add:schema-compat-entry-attribute: objectclass=sudoRole
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%{externalUser})'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%deref_f(\memberUser

[Freeipa-devel] [PATCH] nis and schema-compat: heed userCategory and hostCategory in netgroups

[Nalin Dahyabhai]

It looks like we missed the userCategory and hostCategory stuff when we
did the original pass at configuring the nis server and schema compat
plugins for netgroups.  Here's a proposed change which should empty the
right fields when we have one or the other set to ALL.

Nalin
commit 7a76e7b25026ebd1596040892bc95e1deda777eb
Author: Nalin Dahyabhai na...@redhat.com
Date:   Wed Nov 3 18:57:33 2010 -0400

- add support for hostCategory and userCategory

diff --git a/install/share/nis.uldif b/install/share/nis.uldif
index d6a3644..f23b49e 100644
--- a/install/share/nis.uldif
+++ b/install/share/nis.uldif
@@ -80,5 +80,5 @@ default:nis-map: netgroup
 default:nis-base: cn=ng, cn=alt, $SUFFIX
 default:nis-filter: (objectClass=ipanisNetgroup)
 default:nis-key-format: %{cn}
-default:nis-value-format: %merge( 
,%{memberNisNetgroup},(%link(\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\,\-\,\,\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\,\-\),%{nisDomainName:-}))
+default:nis-value-format: %merge( 
,%{memberNisNetgroup},(%link(\%ifeq(\\\hostCategory\\\,\\\all\\\,\\,\\\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\\\)\,\-\,\,\,\%ifeq(\\\userCategory\\\,\\\all\\\,\\,\\\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\\\)\,\-\),%{nisDomainName:-}))
 default:nis-secure: no
diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index 15ac2a2..22e3141 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -62,7 +62,7 @@ add:schema-compat-entry-rdn: cn=%{cn}
 add:schema-compat-entry-attribute: objectclass=nisNetgroup
 add:schema-compat-entry-attribute: 'memberNisNetgroup=%deref_r(member,cn)'
 add:schema-compat-entry-attribute: 
'memberNisNetgroup=%referred_r(cn=ng,memberOf,cn)'
-add:schema-compat-entry-attribute: 
'nisNetgroupTriple=(%link(%collect(\%{externalHost}\,\%deref(\\\memberHost\\\,\\\fqdn\\\)\,\%deref_r(\\\member\\\,\\\fqdn\\\)\,\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\),-,,,%collect(\%deref(\\\memberUser\\\,\\\uid\\\)\,\%deref_r(\\\member\\\,\\\uid\\\)\,\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\),-),%{nisDomainName:-})'
+add:schema-compat-entry-attribute: 
nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})
 
 # Enable anonymous VLV browsing for Solaris
 dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] #333 plugin to change kerberos principal name when user is renamed

[Nalin Dahyabhai]

On Mon, Oct 25, 2010 at 10:53:19AM -0400, Rob Crittenden wrote:
 Simo Sorce wrote:
 Can you do a modrdn modification on a compat plugin entry ?
 
 Well, right, I don't know :-) And if not, what error would be raised and 
 do/should we catch it?

You should get an insufficient-access (0.17 and earlier) or
unwilling-to-perform (0.18 and later) error result.

Nalin

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

Re: [Freeipa-devel] [PATCH] #333 plugin to change kerberos principal name when user is renamed

[Nalin Dahyabhai]

On Mon, Oct 25, 2010 at 11:45:45AM -0400, Simo Sorce wrote:
 On Mon, 25 Oct 2010 11:42:09 -0400
 Nalin Dahyabhai na...@redhat.com wrote:
 
  On Mon, Oct 25, 2010 at 10:53:19AM -0400, Rob Crittenden wrote:
   Simo Sorce wrote:
   Can you do a modrdn modification on a compat plugin entry ?
   
   Well, right, I don't know :-) And if not, what error would be
   raised and do/should we catch it?
  
  You should get an insufficient-access (0.17 and earlier) or
  unwilling-to-perform (0.18 and later) error result.
 
 And I guess this happens quite early.
 The ipa_modrdn plugin is invoked only as a post op, so if an error is
 thrown earlier I think it is not even invoked.

Right, the error's returned by a preop callback, so the postop callback
in this plugin shouldn't be invoked.

Nalin

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

[Freeipa-devel] [PATCH] fix typo in install/updates/30-automount.update

[Nalin Dahyabhai]

This'll keep cn=default,cn=automount,$SUFFIX from getting a second cn
value that it doesn't need.

Nalin
From 5a1992896dcf33f382b475ef9e09e9b2ff2c48c3 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Mon, 22 Feb 2010 16:23:39 -0500
Subject: [PATCH 1/1] - fix a typo

---
 install/updates/30-automount.update |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/install/updates/30-automount.update 
b/install/updates/30-automount.update
index 93f29a0..3dd4960 100644
--- a/install/updates/30-automount.update
+++ b/install/updates/30-automount.update
@@ -6,7 +6,7 @@ add:cn: automount
 
 dn: cn=default,cn=automount,$SUFFIX
 add:objectClass: nsContainer
-add:cn: automount
+add:cn: default
 
 dn: automountmapname=auto.master,cn=default,cn=automount,$SUFFIX
 add:objectClass: automountMap
-- 
1.7.0

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

[Freeipa-devel] [PATCH] add krbCanonicalName to the schema

[Nalin Dahyabhai]

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 nalin.dahyab...@pobox.com
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

[Freeipa-devel] [PATCH] more basic stuff for krbCanonicalName

[Nalin Dahyabhai]

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 nalin.dahyab...@pobox.com
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 nalin.dahyab...@pobox.com
Date: Thu, 4 Feb 2010 11:07:48 -0500
Subject: [PATCH 2/2] - also

[Freeipa-devel] Certificate enrollment, principal names

[Nalin Dahyabhai]

I think I'm getting closer to having certmonger (the provider of the
ipa-getcert command) be useful enough to throw certificate enrollment
requests at the IPA server, and I've got a couple of questions about how
the server decides what it will issue and what it puts in the
certificates that it issues.

First, how we are we going to be expected to pass, to the server,
information about the certificate we'd like it to issue?

Until now, I've been storing the principal name in a subjectAltName
value in an extensionRequest attribute in the signing request.  I can
actually put quite a bit of information in extensionRequests.

It's not a lot of trouble to also provide that information along with
the signing request (as 1.9.0 expects, at least for the Kerberos
principal name), but if the server's going to be taking direction from
the client on any of these things, it might be more future-proof if it
could parse the request and validate its contents directly.

This would make adding a requested dnsName subjectAltName possible
without breaking any of the existing interfaces -- the client could
request it, or not, or more than one value, and the server would pick
and choose from everything that the client requested when deciding what
to put into a certificate.

The other question is about client authorization:  have we set down the
rules about which client identities are allowed to request what, and
what they get?

I ask because I think that we'll have to use the client host's identity
(via creds obtained using its keytab) to handle the case where the
connection to the CA doesn't become available until long after the
admin's logged out, but when I try that now, requests submitted using
the host's identity are being denied by the access control mechanisms.

Anyone have some insight to share here?

Thanks,

Nalin

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

Re: [Freeipa-devel] Fedora12: Looping detected inside krb5_get_in_tkt

[Nalin Dahyabhai]

On Mon, Oct 12, 2009 at 10:17:21PM -0600, Jason Gerard DeRose wrote:
 To help ensure that my new UI patch wont break our daily builds, I've
 tried building it under Fedora 12 as it has python-assets and
 python-wehjit.  It builds fine, but when I kinit, I get this error:
 
 [r...@fedora12 ~]# kinit ad...@example.com
 Password for ad...@example.com: 
 kinit: Looping detected inside krb5_get_in_tkt while getting initial
 credentials
 
 Anyone have any ideas?

This came up on the upstream list recently; I haven't reproduced it
myself, but it looks like it'll happen if you fail to preauthenticate in
a number of ways where the KDC doesn't return a more-specific error
code.

Does the database entry for ad...@example.com have keys in it?
Did you type the right password?
Is there anything in the KDC logs that provides more detail?
Do you have a packet capture?  The size and contents of the e-data
returned with the error can help narrow it down.

HTH,

Nalin

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