Re: [Freeipa-devel] [RFE] List of IPA realm domains
On 02/06/2013 06:27 PM, Ana Krivokapic wrote:
Hello,
Below is a design page for ticket:
https://fedorahosted.org/freeipa/ticket/2945.
There are a couple of questions in the text.
Thoughts, comments welcome!
http://www.freeipa.org/page/V3/Realm_Domains
Hello,
I don't think we should make special commands for adding/removing of a
single value of multivalued attribute. We should use similar concept as
in server config or dns config.
IMO the commands should be:
realmdomains-show
realmdomains-mod --associatedDomain={defaultdomain,domain1,domain2,..}
we might introduced --add-domain and --del-domain options for
adding/removing of a single value. IIRC we don't have a precedence for
such options, but we've discussed it before [1].
Regarding WEB UI:
Identity section is OK.
ipa host-add command can be hooked to realmdomains-add-domain, to automatically
> add domain of added host to the list of domains associated with IPA
realm
Web UI uses DNS zones list for host-add operation. Does the proposal
mean that it will have to be changed to use realmdomain list? I'm not
sure which way is better.
[1] https://fedorahosted.org/freeipa/ticket/3054
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1085 cert-find command
On 02/06/2013 12:44 AM, Rob Crittenden wrote: This adds a cert-find command for the dogtag backend. Searches can be done by serial number, by subject, revocation reason, issue date, notbefore, notafter and revocation dates. I added some basic tests for this. I made it a separate test file because the cert plugin tests do not use the declarative format and rely on the selfsign backend by default. rob Should I create Web UI in scope of this ticket or a new one? I was also thinking if it's time to implement #191 'Web UI: specify fields to search on' [1]. Maybe in Pilsner. [1] https://fedorahosted.org/freeipa/ticket/191 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] List of IPA realm domains
On Thu, Feb 07, 2013 at 10:55:28AM +0100, Petr Vobornik wrote:
> On 02/06/2013 06:27 PM, Ana Krivokapic wrote:
> >Hello,
> >
> >Below is a design page for ticket:
> >https://fedorahosted.org/freeipa/ticket/2945.
> >
> >There are a couple of questions in the text.
> >
> >Thoughts, comments welcome!
> >
> >http://www.freeipa.org/page/V3/Realm_Domains
> >
>
> Hello,
>
> I don't think we should make special commands for adding/removing of
> a single value of multivalued attribute. We should use similar
> concept as in server config or dns config.
>
> IMO the commands should be:
>
> realmdomains-show
> realmdomains-mod --associatedDomain={defaultdomain,domain1,domain2,..}
>
> we might introduced --add-domain and --del-domain options for
> adding/removing of a single value. IIRC we don't have a precedence
+1, I think having only --associatedDomain is cumbersome and error-prone.
> for such options, but we've discussed it before [1].
>
>
> Regarding WEB UI:
> Identity section is OK.
My first guess was 'IPA Server' but I won't mind if it is put under Identity.
>
> >ipa host-add command can be hooked to realmdomains-add-domain, to
> >automatically
> > add domain of added host to the list of domains associated with
> IPA realm
>
> Web UI uses DNS zones list for host-add operation. Does the proposal
> mean that it will have to be changed to use realmdomain list? I'm
> not sure which way is better.
Does this mean you cannot add hosts managed by a different DNS server or
is it just a convenience option so that the domain name must not always
be specified?
>
> [1] https://fedorahosted.org/freeipa/ticket/3054
> --
> Petr Vobornik
>
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] List of IPA realm domains
On 02/07/2013 12:48 PM, Sumit Bose wrote: On Thu, Feb 07, 2013 at 10:55:28AM +0100, Petr Vobornik wrote: On 02/06/2013 06:27 PM, Ana Krivokapic wrote: ipa host-add command can be hooked to realmdomains-add-domain, to automatically add domain of added host to the list of domains associated with IPA realm Web UI uses DNS zones list for host-add operation. Does the proposal mean that it will have to be changed to use realmdomain list? I'm not sure which way is better. Does this mean you cannot add hosts managed by a different DNS server or is it just a convenience option so that the domain name must not always be specified? It just for convenience. You have to specify domain name, but you are not limited to current dns zones. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] List of IPA realm domains
On Wed, Feb 06, 2013 at 06:27:26PM +0100, Ana Krivokapic wrote: > Hello, > > Below is a design page for ticket: > https://fedorahosted.org/freeipa/ticket/2945. > > There are a couple of questions in the text. about 'Do we also need to check if the domain is accessible through DNS?' I think it would be good to print a warning that no SOA or NS record was found for the domain. But I think there might be cases where the domain is added to the realmdomains first and then the DNS zone is created. So my suggestion would be either - not fail and print a warning or - fail but allow to skip the check with a --force option. I think you should discuss in 'Updates and Upgrades' if and how cn=Realm Domains,cn=ipa,cn=etc,$SUFFIX is created during updates. bye, Sumit > > Thoughts, comments welcome! > > http://www.freeipa.org/page/V3/Realm_Domains > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] List of IPA realm domains
On 7.2.2013 13:38, Sumit Bose wrote: On Wed, Feb 06, 2013 at 06:27:26PM +0100, Ana Krivokapic wrote: Hello, Below is a design page for ticket: https://fedorahosted.org/freeipa/ticket/2945. There are a couple of questions in the text. about 'Do we also need to check if the domain is accessible through DNS?' I think it would be good to print a warning that no SOA or NS record was found for the domain. But I think there might be cases where the domain is added to the realmdomains first and then the DNS zone is created. So my suggestion would be either - not fail and print a warning or - fail but allow to skip the check with a --force option. +1 for --force option I added questions about interaction with "ipa dnszone-add" to design document: http://www.freeipa.org/page/V3/Realm_Domains Should dnszone-del delete associatedDomain when whole DNS zone is being deleted? Should dnszone-add offer an option to create associatedDomain attribute for the new zone? Petr^2 Spacek I think you should discuss in 'Updates and Upgrades' if and how cn=Realm Domains,cn=ipa,cn=etc,$SUFFIX is created during updates. bye, Sumit Thoughts, comments welcome! http://www.freeipa.org/page/V3/Realm_Domains -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] List of IPA realm domains
On Thu, Feb 07, 2013 at 01:57:18PM +0100, Petr Spacek wrote: > On 7.2.2013 13:38, Sumit Bose wrote: > >On Wed, Feb 06, 2013 at 06:27:26PM +0100, Ana Krivokapic wrote: > >>Hello, > >> > >>Below is a design page for ticket: > >>https://fedorahosted.org/freeipa/ticket/2945. > >> > >>There are a couple of questions in the text. > > > >about 'Do we also need to check if the domain is accessible through > >DNS?' I think it would be good to print a warning that no SOA or NS > >record was found for the domain. But I think there might be cases where > >the domain is added to the realmdomains first and then the DNS zone is > >created. So my suggestion would be either > >- not fail and print a warning or > >- fail but allow to skip the check with a --force option. > +1 for --force option > > I added questions about interaction with "ipa dnszone-add" to design document: > http://www.freeipa.org/page/V3/Realm_Domains > > Should dnszone-del delete associatedDomain when whole DNS zone is being > deleted? I think no, because the related host and service objects will still be available. E.g. the zone will be deleted because it will be managed by a different DNS server of the hosts are still in IPA. > > Should dnszone-add offer an option to create associatedDomain > attribute for the new zone? yes, that would be useful. Although I think the hook suggested by Ana during 'ipa host-add' is good, because at this stage the domain is really used in the sense that there is a Kerberos principal with the domain in it. bye, Sumit > > Petr^2 Spacek > > >I think you should discuss in 'Updates and Upgrades' if and how cn=Realm > >Domains,cn=ipa,cn=etc,$SUFFIX is created during updates. > > > >bye, > >Sumit > >> > >>Thoughts, comments welcome! > >> > >>http://www.freeipa.org/page/V3/Realm_Domains > > -- > Petr^2 Spacek > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1085 cert-find command
Petr Vobornik wrote: On 02/06/2013 12:44 AM, Rob Crittenden wrote: This adds a cert-find command for the dogtag backend. Searches can be done by serial number, by subject, revocation reason, issue date, notbefore, notafter and revocation dates. I added some basic tests for this. I made it a separate test file because the cert plugin tests do not use the declarative format and rely on the selfsign backend by default. rob Should I create Web UI in scope of this ticket or a new one? I was also thinking if it's time to implement #191 'Web UI: specify fields to search on' [1]. Maybe in Pilsner. [1] https://fedorahosted.org/freeipa/ticket/191 I'm going to open a UI ticket once the API is finalized. I didn't want to give you a moving target to work against. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 362 Add LDAP server fallback to client installer
Martin Kosek wrote:
On 02/06/2013 04:12 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/05/2013 05:57 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/04/2013 05:59 PM, Rob Crittenden wrote:
Martin Kosek wrote:
When ipa-client-install is run without --server option, it tries to
search SRV records for IPA/LDAP server hostname, but it returns only
the first record found and when the LDAP server on that hostname is
not available, the whole client installation fails.
Get all LDAP SRV records instead and fallback to next hostname when
the current one is not available.
https://fedorahosted.org/freeipa/ticket/3388
I worked on the same ticket, unfortunately, but I didn't mark it as assigned
which caused some duplicate effort. Sorry about that.
I came up with a very similar solution but took it a bit further. This
expands
the treatment of the discovered servers as a list of servers rather than a
single value.
I do a bit more aggressive testing of all servers returned and remove any
from
the list that are not IPA servers. A server not responding is left in the
configured list.
rob
1) (minor) If I connected IPA host to other IPA server before next enrollment,
there will be outdated /etc/ipa/ca.crt. This will cause all tries to
connect to
IPA server to fail with TLS error, but without giving any clue to user...
Yeah, this can be a problem but I'm going to leave things as-is for now. I
believe we have a separate ticket to clean this up. I don't want to combine too
many things into this patch, it is disruptive enough.
# ipa-client-install
Provide your IPA server name (ex: ipa.example.com):
He would need to reach out to the log to find this line:
LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert
with the same issuer/serial as an existing cert, but that is not the same
cert.
I am thinking if we should not expose some LDAP errors after all? To give some
clue to user...
Yeah, I switched the LDAP error unhandled exception back from debug to error.
2) (minor) While we are touching these errors I would also fix a typo there
:-)
...
if isinstance(err, ldap.INAPPROPRIATE_AUTH):
root_logger.debug("LDAP Error: Anonymous acces not allowed")
return [NO_ACCESS_TO_LDAP] ^
...
Heh, ok.
3) (Regression) You neither set ds.server nor add server to valid_servers when
anonymous access is not enabled. The installer then does not try to connect to
this server even though the installation would succeed:
...
elif ldapret[0] == NO_ACCESS_TO_LDAP or ldapret[0] ==
NO_TLS_LDAP:
ldapaccess = False
...
Good point. The handling for this is done a bit later so I need to defer a
little processing but it should work now.
4) (Regression) Client will now report success in discovery even when the
server is down:
# ipa-client-install
Unable to verify that vm-037.idm.lab.bos.redhat.com (realm
IDM.LAB.BOS.REDHAT.COM) is an IPA server
Discovery was successful!
Hostname: vm-148.idm.lab.bos.redhat.com
Realm: IDM.LAB.BOS.REDHAT.COM
DNS Domain: idm.lab.bos.redhat.com
IPA Server: vm-037.idm.lab.bos.redhat.com
BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
Continue to configure the system with these values? [no]: y
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for ad...@idm.lab.bos.redhat.com:
Kerberos authentication failed
kinit: Generic error (see e-text) while getting initial credentials
Please make sure the following ports are opened in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly
after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
IPA client is not configured on this system.
LDAP on vm-037 in this case is down. I think this would cause a regression
too,
because previously we simply reported that no discovered server is available
and let user enter the server manually.
Fixed.
IMO we are trying to be too smart when processing the (discovered) servers.
Why
do we need to process and verify _all_ discovered servers even when the
list is
not written anywhere in case of SRV lookup? I think it causes unnecessary
traffic on network - we should connect to the first server available.
That's a good point. Now we except on the first discovered server.
I think for user-provided servers we still want to verify them all since they
will be hardcoded in a config file.
5) In ipa-client-automount:
+# Now confirm that our server is an IPA server. Stop checking on the
first
+# success so we know we have at least one good one.
+for server in servers:
+root_logger.debug("Verifying that %s is an IPA server" % server)
+ldapret = ds.ipacheckldap(server, api.env.realm)
In case of successful autodiscovery, this looks redun
Re: [Freeipa-devel] [PATCH] 362 Add LDAP server fallback to client installer
On 02/07/2013 04:03 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/06/2013 04:12 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/05/2013 05:57 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/04/2013 05:59 PM, Rob Crittenden wrote:
Martin Kosek wrote:
When ipa-client-install is run without --server option, it tries to
search SRV records for IPA/LDAP server hostname, but it returns only
the first record found and when the LDAP server on that hostname is
not available, the whole client installation fails.
Get all LDAP SRV records instead and fallback to next hostname when
the current one is not available.
https://fedorahosted.org/freeipa/ticket/3388
I worked on the same ticket, unfortunately, but I didn't mark it as
assigned
which caused some duplicate effort. Sorry about that.
I came up with a very similar solution but took it a bit further. This
expands
the treatment of the discovered servers as a list of servers rather than a
single value.
I do a bit more aggressive testing of all servers returned and remove any
from
the list that are not IPA servers. A server not responding is left in the
configured list.
rob
1) (minor) If I connected IPA host to other IPA server before next
enrollment,
there will be outdated /etc/ipa/ca.crt. This will cause all tries to
connect to
IPA server to fail with TLS error, but without giving any clue to user...
Yeah, this can be a problem but I'm going to leave things as-is for now. I
believe we have a separate ticket to clean this up. I don't want to
combine too
many things into this patch, it is disruptive enough.
# ipa-client-install
Provide your IPA server name (ex: ipa.example.com):
He would need to reach out to the log to find this line:
LDAP Error: Connect error: TLS error -8054:You are attempting to import a
cert
with the same issuer/serial as an existing cert, but that is not the same
cert.
I am thinking if we should not expose some LDAP errors after all? To give
some
clue to user...
Yeah, I switched the LDAP error unhandled exception back from debug to error.
2) (minor) While we are touching these errors I would also fix a typo there
:-)
...
if isinstance(err, ldap.INAPPROPRIATE_AUTH):
root_logger.debug("LDAP Error: Anonymous acces not
allowed")
return [NO_ACCESS_TO_LDAP] ^
...
Heh, ok.
3) (Regression) You neither set ds.server nor add server to valid_servers
when
anonymous access is not enabled. The installer then does not try to
connect to
this server even though the installation would succeed:
...
elif ldapret[0] == NO_ACCESS_TO_LDAP or ldapret[0] ==
NO_TLS_LDAP:
ldapaccess = False
...
Good point. The handling for this is done a bit later so I need to defer a
little processing but it should work now.
4) (Regression) Client will now report success in discovery even when the
server is down:
# ipa-client-install
Unable to verify that vm-037.idm.lab.bos.redhat.com (realm
IDM.LAB.BOS.REDHAT.COM) is an IPA server
Discovery was successful!
Hostname: vm-148.idm.lab.bos.redhat.com
Realm: IDM.LAB.BOS.REDHAT.COM
DNS Domain: idm.lab.bos.redhat.com
IPA Server: vm-037.idm.lab.bos.redhat.com
BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
Continue to configure the system with these values? [no]: y
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for ad...@idm.lab.bos.redhat.com:
Kerberos authentication failed
kinit: Generic error (see e-text) while getting initial credentials
Please make sure the following ports are opened in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly
after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
IPA client is not configured on this system.
LDAP on vm-037 in this case is down. I think this would cause a regression
too,
because previously we simply reported that no discovered server is available
and let user enter the server manually.
Fixed.
IMO we are trying to be too smart when processing the (discovered) servers.
Why
do we need to process and verify _all_ discovered servers even when the
list is
not written anywhere in case of SRV lookup? I think it causes unnecessary
traffic on network - we should connect to the first server available.
That's a good point. Now we except on the first discovered server.
I think for user-provided servers we still want to verify them all since they
will be hardcoded in a config file.
5) In ipa-client-automount:
+# Now confirm that our server is an IPA server. Stop checking on the
first
+# success so we know we have at least one good one.
+for server in servers:
+root_logger.debug("Verifying that %s is an IPA server" % server)
+ldapret = ds.ipacheckldap(server, api.env.realm)
In cas
[Freeipa-devel] [PATCH] Add delegation info to MS-PAC
This information is not strictly required but is part of the MS-PAC
specification and I had some time to kill on the plane on my last trip
back.
I tested it briefly with cross-realm trusts and it seem to work fine.
Neither IPA nor AD2012 complained when looking at PACs, do far.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
>From 70e3b569618004e30fbb5e7b974e158383fab6ad Mon Sep 17 00:00:00 2001
From: Simo Sorce
Date: Tue, 5 Feb 2013 17:50:55 -0500
Subject: [PATCH] Add Delegation Info to MS-PAC
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 162 +++-
1 file changed, 160 insertions(+), 2 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index ee1c6124f8d04cb10d091f11883834620c5c35ea..5323c121897ad8bd23c8a0ae2b88d3c526f94342 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -704,6 +704,8 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext,
goto done;
}
+/* PAC_LOGON_NAME and PAC_TYPE_UPN_DNS_INFO are automatically added
+ * by krb5_pac_sign() later on */
/* == Search PAC info == */
kerr = ipadb_deref_search(ipactx, ied->entry_dn, LDAP_SCOPE_BASE,
@@ -1346,9 +1348,150 @@ done:
return kerr;
}
+static krb5_error_code get_delegation_info(krb5_context context,
+TALLOC_CTX *memctx, krb5_data *pac_blob,
+struct PAC_CONSTRAINED_DELEGATION_CTR *info)
+{
+DATA_BLOB pac_data;
+enum ndr_err_code ndr_err;
+
+pac_data.length = pac_blob->length;
+pac_data.data = (uint8_t *)pac_blob->data;
+
+ndr_err = ndr_pull_union_blob(&pac_data, memctx, info,
+ PAC_TYPE_CONSTRAINED_DELEGATION,
+ (ndr_pull_flags_fn_t)ndr_pull_PAC_INFO);
+if (!NDR_ERR_CODE_IS_SUCCESS(ndr_err)) {
+return KRB5_KDB_INTERNAL_ERROR;
+}
+
+return 0;
+}
+
+static krb5_error_code save_delegation_info(krb5_context context,
+TALLOC_CTX *memctx,
+struct PAC_CONSTRAINED_DELEGATION_CTR *info,
+krb5_data *pac_blob)
+{
+DATA_BLOB pac_data;
+enum ndr_err_code ndr_err;
+
+ndr_err = ndr_push_union_blob(&pac_data, memctx, info,
+ PAC_TYPE_CONSTRAINED_DELEGATION,
+ (ndr_push_flags_fn_t)ndr_push_PAC_INFO);
+if (!NDR_ERR_CODE_IS_SUCCESS(ndr_err)) {
+return KRB5_KDB_INTERNAL_ERROR;
+}
+
+free(pac_blob->data);
+pac_blob->data = malloc(pac_data.length);
+if (pac_blob->data == NULL) {
+pac_blob->length = 0;
+return ENOMEM;
+}
+memcpy(pac_blob->data, pac_data.data, pac_data.length);
+pac_blob->length = pac_data.length;
+
+return 0;
+}
+
+static krb5_error_code ipadb_add_transited_service(krb5_context context,
+ krb5_db_entry *proxy,
+ krb5_db_entry *server,
+ krb5_pac old_pac,
+ krb5_pac new_pac)
+{
+struct PAC_CONSTRAINED_DELEGATION_CTR info;
+krb5_data pac_blob = { 0 , 0, NULL };
+krb5_error_code kerr;
+TALLOC_CTX *tmpctx;
+uint32_t i;
+char *tmpstr;
+
+tmpctx = talloc_new(NULL);
+if (!tmpctx) {
+kerr = ENOMEM;
+goto done;
+}
+
+kerr = krb5_pac_get_buffer(context, old_pac,
+ KRB5_PAC_DELEGATION_INFO, &pac_blob);
+if (kerr != 0 && kerr != ENOENT) {
+goto done;
+}
+
+if (pac_blob.length != 0) {
+kerr = get_delegation_info(context, tmpctx, &pac_blob, &info);
+if (kerr != 0) {
+goto done;
+}
+} else {
+info.info = talloc_zero(tmpctx, struct PAC_CONSTRAINED_DELEGATION);
+if (!info.info) {
+kerr = ENOMEM;
+goto done;
+}
+}
+
+krb5_free_data_contents(context, &pac_blob);
+memset(&pac_blob, 0, sizeof(krb5_data));
+
+kerr = krb5_unparse_name(context, proxy->princ, &tmpstr);
+if (kerr != 0) {
+goto done;
+}
+
+info.info->proxy_target.string = talloc_strdup(tmpctx, tmpstr);
+krb5_free_unparsed_name(context, tmpstr);
+if (!info.info->proxy_target.string) {
+kerr = ENOMEM;
+goto done;
+}
+
+i = info.info->num_transited_services;
+
+info.info->transited_services = talloc_realloc(tmpctx,
+info.info->transited_services,
+struct lsa_String, i + 1);
+if (!info.info->transited_services) {
+kerr = ENOMEM;
+goto done;
+}
+
+kerr = krb5_unparse_name(context, server->princ, &tmpstr);
+if (kerr != 0) {
+goto done;
+}
+
+info.info->transited_servic
Re: [Freeipa-devel] [PATCH] 362 Add LDAP server fallback to client installer
Martin Kosek wrote:
On 02/07/2013 04:03 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/06/2013 04:12 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/05/2013 05:57 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 02/04/2013 05:59 PM, Rob Crittenden wrote:
Martin Kosek wrote:
When ipa-client-install is run without --server option, it
tries to
search SRV records for IPA/LDAP server hostname, but it returns
only
the first record found and when the LDAP server on that
hostname is
not available, the whole client installation fails.
Get all LDAP SRV records instead and fallback to next hostname
when
the current one is not available.
https://fedorahosted.org/freeipa/ticket/3388
I worked on the same ticket, unfortunately, but I didn't mark it as
assigned
which caused some duplicate effort. Sorry about that.
I came up with a very similar solution but took it a bit
further. This
expands
the treatment of the discovered servers as a list of servers
rather than a
single value.
I do a bit more aggressive testing of all servers returned and
remove any
from
the list that are not IPA servers. A server not responding is
left in the
configured list.
rob
1) (minor) If I connected IPA host to other IPA server before next
enrollment,
there will be outdated /etc/ipa/ca.crt. This will cause all tries to
connect to
IPA server to fail with TLS error, but without giving any clue to
user...
Yeah, this can be a problem but I'm going to leave things as-is
for now. I
believe we have a separate ticket to clean this up. I don't want to
combine too
many things into this patch, it is disruptive enough.
# ipa-client-install
Provide your IPA server name (ex: ipa.example.com):
He would need to reach out to the log to find this line:
LDAP Error: Connect error: TLS error -8054:You are attempting to
import a
cert
with the same issuer/serial as an existing cert, but that is not
the same
cert.
I am thinking if we should not expose some LDAP errors after all?
To give
some
clue to user...
Yeah, I switched the LDAP error unhandled exception back from
debug to error.
2) (minor) While we are touching these errors I would also fix a
typo there
:-)
...
if isinstance(err, ldap.INAPPROPRIATE_AUTH):
root_logger.debug("LDAP Error: Anonymous acces
not
allowed")
return [NO_ACCESS_TO_LDAP] ^
...
Heh, ok.
3) (Regression) You neither set ds.server nor add server to
valid_servers
when
anonymous access is not enabled. The installer then does not try to
connect to
this server even though the installation would succeed:
...
elif ldapret[0] == NO_ACCESS_TO_LDAP or
ldapret[0] ==
NO_TLS_LDAP:
ldapaccess = False
...
Good point. The handling for this is done a bit later so I need to
defer a
little processing but it should work now.
4) (Regression) Client will now report success in discovery even
when the
server is down:
# ipa-client-install
Unable to verify that vm-037.idm.lab.bos.redhat.com (realm
IDM.LAB.BOS.REDHAT.COM) is an IPA server
Discovery was successful!
Hostname: vm-148.idm.lab.bos.redhat.com
Realm: IDM.LAB.BOS.REDHAT.COM
DNS Domain: idm.lab.bos.redhat.com
IPA Server: vm-037.idm.lab.bos.redhat.com
BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
Continue to configure the system with these values? [no]: y
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for ad...@idm.lab.bos.redhat.com:
Kerberos authentication failed
kinit: Generic error (see e-text) while getting initial credentials
Please make sure the following ports are opened in the firewall
settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client
working properly
after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
IPA client is not configured on this system.
LDAP on vm-037 in this case is down. I think this would cause a
regression
too,
because previously we simply reported that no discovered server
is available
and let user enter the server manually.
Fixed.
IMO we are trying to be too smart when processing the
(discovered) servers.
Why
do we need to process and verify _all_ discovered servers even
when the
list is
not written anywhere in case of SRV lookup? I think it causes
unnecessary
traffic on network - we should connect to the first server
available.
That's a good point. Now we except on the first discovered server.
I think for user-provided servers we still want to verify them all
since they
will be hardcoded in a config file.
5) In ipa-client-automount:
+# Now confirm that our server is an IPA server. Stop
checking on the
first
+# success so we know we have at least one good one.
+for server in servers:
+root_logger.debug("Verifying that %s is an IPA server" %
server)
+ldapret = ds.ipacheckldap(server, ap
Re: [Freeipa-devel] [PATCH] 1085 cert-find command
Hi, On 6.2.2013 00:44, Rob Crittenden wrote: This adds a cert-find command for the dogtag backend. Searches can be done by serial number, by subject, revocation reason, issue date, notbefore, notafter and revocation dates. I added some basic tests for this. I made it a separate test file because the cert plugin tests do not use the declarative format and rely on the selfsign backend by default. rob I have one design question: why do you emulate object interface with Command plugins? Wouldn't it be better to add an actual Object plugin and Method plugins? That way you would not have to duplicate the Object bits for certs and as a result, the code would be cleaner and consistent with the rest of our plugins. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
