Re: ADFS Not Compatible with FIPS?
- From: "b" <dbsisk@xxxxxxxxx>
- Date: 15 Sep 2006 14:01:06 -0700
Yes, I apologize for the cross-posting in this group, but the problem
seemed very similar and frankly, there is not that much info out there
on this...
Thanks _very_ much for your time and posts on this. I will continue to
pursue this. If I find out anything, I will post back in this ng for
all to reference.
thanks again...
Joe Kaplan wrote:
I see. This problem is a manifestation of the same problem that ADFS has,
but has actually nothing to do with ADFS. I'd suggest asking your question
in a group that supports Click Once, not AD. :)
My guess is that if ClickOnce is using code that uses a non-FIPS alg, unless
you can get a patch, you can't use it with FIPS either. That is essentially
the result Susie has with ADFS currently and probably applies to you as
well.
ClickOnce has a MUCH broader audience than ADFS does and has been around
longer, so there may already be a solution for you somewhere.
Best of luck,
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"b" <dbsisk@xxxxxxxxx> wrote in message
news:1158350866.048674.278080@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Something's not working. We have FIPS enabled on our dev machines and
when we attempt to publish, the process stops with the following error:
"Problem generating manifest. This implementation is not a part of the
Windows Platform FIPS validated cryptographic solution."
This is a really simple inventory application that uses absolutely no
crypto code. We can even publish (turning FIPS off), install on a
machine that _does_ have FIPS enabled and the app will run. I would
think that if it had non-compliant crypto code in the app, it would not
run with FIPS enabled (we've seen this before where we developed an app
on a non-FIPS machine and then installed on a FIPS enabled machine and
the app didn't work).
It appears the ClickOnce security setting uses a hashing algorithm that
isn't FIPS compliant (I'm guessing). So when we have FIPS enabled on
the dev machine and attempt to publish, we get errors... When you go
into the solution properties and turn off the ClickOnce security on the
Security tab. You can build, but you can't publish because it turns on
the ClickOnce switch prior to perfoming the publish...
Any suggestions you have would be greatly appreciated...
Joe Kaplan wrote:
If you have no crypto code at all, it is hard to imagine why this is a
problem for you. Are you just worried that you might have a problem, or
is
something not working? If it is not working, you must have some crypto
code
somewhere, although maybe not in the parts you wrote yourself.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"b" <dbsisk@xxxxxxxxx> wrote in message
news:1158328949.835134.12970@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Please post what you find out. I ran across this discussion in my
attempts to find out how to build a deployment solution for a small
windows app that has absolutely no cryptographic or ASP code in it.
However, the system we are developing this on must have FIPS set (gov't
environment). Have I missed something? _Is_ there a way to do that?
DB
Susieber wrote:
Well, the <machineKey> setting didn't work. We even applied it to the
Fed
Servers' web.configs. Apparently what we've learned here is that ADFS
is
not
a FIPS-compliant application. Once FIPS is enabled, I cannot access
the
Federation Server Service URLs from the federation servers themselves.
In fact, according to KB 911722, ASP.NET 2.0 uses the AES algorithm
when
it
processes view state data. The AES algorithm is not currently a
Federal
Information Processing Standard (FIPS)-compliant algorithm.
So we plan to talk to Microsoft about this tomorrow. The blog link you
sent
explains why FIPS is a requirement for this particular evaluation
we're
doing.
I'll let you know what we ultimately find out from MSFT on this. No
doubt
it's fixed in Vista. We'll see.
"Joe Kaplan" wrote:
Here's a blog post I found by .NET security luminary Shawn Farkas
that
sheds
a little more light on this:
http://blogs.msdn.com/shawnfa/archive/2005/05/16/417975.aspx
It doesn't really suggest whether there is a practical solution to
this
particular problem though.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Susieber" <Susieber@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9EEF070B-6B09-476D-A01D-3B35A36F101B@xxxxxxxxxxxxxxxx
Thanks, Joe. I re-enabled SChannel, but got no events. Then the
client
generated a different error (none of this seems to be consistently
reproducible) - and the error was FIPS-specific:
This implementation is not part of the Windows Platform FIPS
validated
cryptographic algorithms.
Some research led me to find out that It's looking like ASP .NET
2.0
uses
the AES algorithm, but it is not a FIPS-compliant algorithm. See
http://support.microsoft.com/kb/911722/en-us?spid=8940&sid=291.
We are going to try a workaround mentioned in that article - it's
a
<machineKey> entry to add to the claimapp's web.config file.
"Joe Kaplan" wrote:
Do you still have Schannel event logging enabled in debug mode?
Do
you
get
any interesting errors on the machine that is establishing the
connection?
This might be something that can be configured around, especially
if
it
is
the SSL part of ADFS and not the token signing part. I've never
dealt
with
this problem though, so I really don't know. This might be worth
opening
an
official support inquiry with MS to ensure that it gets taken
care
of.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Susieber" <Susieber@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6CE110B6-34AC-4AB4-964F-36D1CE9E3EDC@xxxxxxxxxxxxxxxx
Has anyone out there tried enabling FIPS-compliant algorithms
on
Windows
Server in an ADFS environment?
We just discovered that this setting is the cause of many of
our
past
ADFS
configuration failures. When we enable _cryptography: Use FIPS
compliant
algorithms for encryption, hashing, and signing_ in the domain
security
policy, the ADFS trust breaks.
The ADFS client can access the Web server with the TLS 1.0
setting
enabled
in IE. But the federation servers stop talking to each other,
and
the
client
gets the discoverclientrealm page but eventually just gives up
after
that
with a page not displayable type error.
According to the MSKB, this FIPS setting affects Terminal
Services
and
EFS,
so it doesn't surprise me that it affects ADFS.
Anyone else been able to track down a fix (other than disabling
FIPS)?
TIA,
Susie
.
- Follow-Ups:
- References:
- Re: ADFS Not Compatible with FIPS?
- From: Joe Kaplan
- Re: ADFS Not Compatible with FIPS?
- From: Joe Kaplan
- Re: ADFS Not Compatible with FIPS?
- From: Susieber
- Re: ADFS Not Compatible with FIPS?
- From: b
- Re: ADFS Not Compatible with FIPS?
- From: Joe Kaplan
- Re: ADFS Not Compatible with FIPS?
- From: b
- Re: ADFS Not Compatible with FIPS?
- From: Joe Kaplan
- Re: ADFS Not Compatible with FIPS?
- Prev by Date: Re: ADAM and Windows Address Book
- Next by Date: DFS Problems with secondary DC unavailable
- Previous by thread: Re: ADFS Not Compatible with FIPS?
- Next by thread: Re: ADFS Not Compatible with FIPS?
- Index(es):
Relevant Pages
|
