I agree that there is a certain amount of pain with certs and ADFS, although
I don't think it is really that hard, especially if you go the commercial
route. The thing I like about it is that since it requires you to get this
working to use it, it is secure by default. You have little ability to
hoist yourself by your own petards, so to speak. :)
There are really two parts to the ADFS cert story, the SSL/HTTP part and the
token signing cert part. The SSL/HTTP part is a little more straightforward
and is the kind of thing that lots of organizations do successfully already
on their public websites now. You really only tend to get yourself in
trouble if you want to self issue certs and do things like issue from your
own root or publish your CRL in a non-public place.
The token signing cert part of ADFS is much more black magic and needs more
guidance. Even with certs that work perfectly fine for SSL, we had trouble
using them for token signing due to the additional CRL checking that ADFS
does and had to disable that in policy. I think similar things happened to
you guys with one of your partner's token signing certs in your own internal
implementation. CRL is an important idea whose implementation is basically
broken in the general case, as there is no reasonable way to always get the
CRL programmatically. Windows could do a lot better with tool support for
troubleshooting this and better error messages though (kind of like Kerberos
delegation; too hard as it stands!).
I'm sure my experiences are influenced by the fact that I already know a
fair amount about certs and SSL, having spent a full year of my life
implementing an automated certificate provisioning system for end user
signing and encryption certs that ties into our overall identity management
process. I can totally see how there is a bunch of mumbo jumbo to overcome
for those not really familiar with PKI. At least in this case, though, the
mumbo jumbo (PKI) is pretty much the same on Linux or Sun as it is on
Windows. It doesn't really hurt the adoption of protocol itself across
platforms.
I also think the ADFS step by step guide leads people down a dark path, in
that all the demos are set up with selfssl and self-issued certs, which are
ok for demos, but not cool for production (IMO). The path to get from the
demo set up in step by step to your actual scenario is not always easy to
do. I think our internal proof of concept was more successful because we
tried to build our POC the way we thought we'd actually use the product
internally, rather than using the "Adatum/Trey Research" scenarios.
As with most new things that take some thought to implement, the skills and
experiences needed to crank out good implemenations quickly will lag the
product for a while. I'm sure the first year or two (or maybe more!) of AD
installs were slow and a little crappy too. I still like the product
though. :) I think the places where it is sound, it is very sound. It has
a good base to build on.
Joe K.
----- Original Message -----
From: "Eric Fleischman" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Sunday, September 24, 2006 1:25 PM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
Yes, we should file a bug for AD. I'll take this offline with you.
On the SSL front, it's interesting that you see this as a strength of
ADFS. I would argue the opposite. Cert infrastructures are non-trivial
to configure or maintain, I always saw it as a downside to ADFS that it
requires one to get a PhD is certology and make this work not only for
you but across organizations, assuming you use it in this way.
Of course, the real solution to all of this is making a cert
infrastructure as easy to run as, say, the key infrastructure that makes
Kerberos "just work" for you.
~Eric
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Sunday, September 24, 2006 10:49 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP
That's very cool, Eric. I had no idea that setting existed in ADAM.
Any
change of sneaking that into the AD stack?
I agree that it only solves half the problem, but at least by preventing
this from working at all, it keeps people from setting up apps that will
do
unsecure simple binds thousands of times per day for years. There is
only
so much you can do.
I also agree that SSL just isn't that easy and can't be, just because of
the
way it works. That doesn't stop me from wishing it was. :) One thing I
like about ADFS is that you have to use SSL to play, so you can't even
get
yourself in trouble.
I'll definitely file a bug on the audit thing. I think that would be
nice,
even with ADAM in the mode to reject insecure simple binds, because you
could find out which clients are attempting it.
Joe K.
----- Original Message -----
From: "Eric Fleischman" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Sunday, September 24, 2006 11:48 AM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
I'd love to see an AD and ADAM option that would allow the DS to
reject simple bind operations on non-SSL ports
We agree. That's why we built it in to the product. :) Well, in to ADAM
that is.
See object CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,CN={<GUID>}. Check out the attribute
msds-other-settings, value named RequireSecureSimpleBind=0. Change that
0 to a 1, then you have enabled the protection.
I would point out, this does not prevent a client from *presenting* a
password via simple bind w/o connection security, only from the
operation succeeding. So you could still present a password (thereby
showing it to an attacker), it's just that it won't work. This is
training with the stick, not the carrot.
It's akin to saying, I can protect your SSN from working when you scream
it to me in a room full of people (ie, require you write it on a piece
of paper and pass it over), but I can't stop you from screaming, only
punish you when you make this bad choice.
Another thing that would be helpful would be an unencrypted simple
bind
audit event that could be configured, so that you could find the IP
address of any client issuing these operations and track them down.
This is a good idea. Can you file a bug for this? I have thought of
doing this before but never thought anyone would appreciate things like
this. :)
Now, if it was only easy to force all DCs and ADAM
instances to have valid server certs, we'd be in business. :)
I think it goes w/o saying, but this is impossible. The definition of
"valid" is in the eye of the beholder. For example, to some a
self-signed cert, trusted by no one, is invalid for the DS. However, to
the person that explicitly trusted that cert on their LDAP clients, it's
perfectly fine. That's just one example, the same could be said for
nearly every wonky cert config you think of, especially when you
consider ADAM in the mix.
~Eric
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
