Re: Issue 35 in direct-certificate-discovery-tool: dts517 test flaw or improper ldap configuation

[direct-certifica...@googlecode.com]

Comment #1 on issue 35 by david.de...@nitorgroup.com: dts517 test flaw or
improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

Thank you for bringing this up and apologies for taking so long to respond.
At this moment we are trying to determine the exact requirements to ensure
we are not over testing. This project arose out of an effort with the
Office of the National Coordinator for Health IT. One of the questions that
our testing team asked was this exact question: From: Test team

Question: Are all LDAP servers required to be mirrors of one another? If
not, then would the System need to progress down a list of SRV records to
find a valid direct certificate?


Answer: From out DirectTrust call we were told that only DNS Servers are
required to be mirrors and a system would ned to progress through the SRV
records to find an LDAP service that returns a valid certificate.
added IG to req 2 3/23/12

---

That was back in March. We will follow up again with either the Direct
community or with ONC to determine if the answer we were given back in
March is accurate.

[direct-certifica...@googlecode.com]

Comment #2 on issue 35 by dca...@meditech.com: dts517 test flaw or improper
ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

OK, thank you. I will be awaiting your response.

[direct-certifica...@googlecode.com]

Updates:
Owner: edward.o...@nitorgroup.com
Labels: -Type-Defect Type-Task

Comment #3 on issue 35 by edward.o...@nitorgroup.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

(No comment was entered for this change.)

[direct-certifica...@googlecode.com]

Updates:
Owner: Sandeep....@nitorgroup.com

Comment #4 on issue 35 by edward.o...@nitorgroup.com: dts517 test flaw or

[direct-certifica...@googlecode.com]

Comment #5 on issue 35 by pbspamfi...@gmail.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

My thought on this when I saw Greg's comment is that if one is serving the
same data on multiple instances of the same image for back up or load
balancing it is intended to be consistent. So I agree and copied over the
certificate so it would work with the test case where it was missing. It's
also possible to set up replication.

Therefore this was a server misconfiguration. Note this is somewhat because
one had to use the SRV record to find the CERT via discovery.

IE the endpoint is not known initially so that tracks the applicability
statement.

If one was searching a known location (read the S&I Guide)then one would
have different expectations that the data would be maintained correctly as
mentioned in the comment and replicated, or done with a chain or referral.

It's a fine point of distinction but one I have stressed that LDAP is not
meant to be taken as a LDAP server, but LDAP in the strict definition as an
access protocol as it is defined in the normative RFC.

Therefore if one knew already where to connect, then one would
connect and then navigate or search the right entry, and then get to the
right entry based on chaining and referrals within the DIT. That's a
different test case.

So in this case it's a server configuration error, based on the
expectations, but in using a DIT it would go find the right information for
you, if you knew the entry point and were properly authenticated.

[direct-certifica...@googlecode.com]

Comment #6 on issue 35 by pbspamfi...@gmail.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

That was only for DTS 517 BTW.

[direct-certifica...@googlecode.com]

Comment #7 on issue 35 by dca...@meditech.com: dts517 test flaw or improper
ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

I'm not sure what was changed, but DTS517 is not accurate based on its
description anymore:
Query for Direct address from LDAP servers based on priority value - one
LDAP Instance does not return a valid certificate.

It first tries to query directsrv.testteam.us on port 389, which times out.
Then it queries directsrv.testteam.us on port 10389, and finds a valid
certificate.

It never finds an invalid certificate.


Also, I reported this on the google group, but it's still not fixed. Email
messages are being rejected when sent to direct3.testteam.us (DTS507 and
DTS 517).

[direct-certifica...@googlecode.com]

Comment #8 on issue 35 by dca...@meditech.com: dts517 test flaw or improper
ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

direct3.testteam.us is responding now. The issue with the DTS 517 Test Case
not matching its description still exists.

[direct-certifica...@googlecode.com]

Updates:
Status: Accepted
Labels: Component-Docs

Comment #10 on issue 35 by michal.k...@esacinc.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

[direct-certifica...@googlecode.com]

Comment #11 on issue 35 by michal.k...@esacinc.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

You are correct that the dts517 test case is incorrectly set up on the
testteam.us instance. Specifically, the second LDAP service hit (priority
1, weight 0, port 10389) should have a matching inetOrgPerson record (by
the mail attribute), but no corresponding userCertificate attribute. Thus,
the certificate hosted in the third LDAP service (priority 2, weight 0,
port 11389) should be used.

I am currently in the middle of phasing out the testteam.us, so it will
likely not be updated/fixed. I'll keep this issue open until the
documentation + official instance are correct.

[direct-certifica...@googlecode.com]

Comment #12 on issue 35 by dca...@meditech.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

OK, thanks.

Has there been any response regarding the validity of DTS 517 as a test
case in general? I still think it is in opposition to LDAP/SRV record
specifications.

[direct-certifica...@googlecode.com]

Comment #13 on issue 35 by michal.k...@esacinc.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

If you are referring to the fact that the first LDAP service is
non-existent, I think it is a perfectly valid scenario. An organization
with considerable infrastructure will likely have many (mirrored,
loud-balanced, etc) LDAP (and other) services running. If one of the
instances dies, things should failover gracefully.

In regards to the inetOrgPerson entry missing a userCertificate attribute
on the second LDAP service, this too is valid. Neither the mail nor
userCertificate attributes are required by the inetOrgPerson schema.

[direct-certifica...@googlecode.com]

Comment #14 on issue 35 by dca...@meditech.com: dts517 test flaw or

improper ldap configuation
http://code.google.com/p/direct-certificate-discovery-tool/issues/detail?id=35

Please read my initial post. Yes, it's valid that if a server is down, we
should go on to the next server. That is the purpose of having multiple
servers.

It is NOT valid that when a server contains no certificate or an invalid
certificate that we should go on to the next server. This nullifies the
load-balancing nature of SRV records, because in the case we find no
certificate we will be checking *every single server*. All servers in a SRV
group should either be mirrored or use referrals.