see sharp RSS 2.0
# Friday, 28 February 2014

A small utility that signs federation metadata.

MetadataSigner[1].zip (56.86 KB)
it requires .NET 4.5

Friday, 28 February 2014 11:03:13 (Mitteleuropäische Zeit, UTC+01:00)  #    -
Authentication | Certificates
# Monday, 28 January 2013

There is an interesting article on how to enable tracing/logging in AD FS 2.0 on MSDN.

However the brand new Version 2.1 is located in a slightly different place:

  1. the config file is no longer located in
    %ProgramFiles%\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config 
    instead you can find it here:
    %WINDIR%\ADFS\Microsoft.IdentityServer.Servicehost.exe.config 
  2. Configure the System.diagnostics as stated in the article
  3. the wevtutil command has to use a different Provider.
    instead of
    wevtutil sl “AD FS 2.0 Tracing/Debug” /L:5 
    you have to use:

    wevtutil sl "AD FS Tracing/Debug" /L:5

  4. restart the AD FS Service


Monday, 28 January 2013 15:11:29 (Mitteleuropäische Zeit, UTC+01:00)  #    -
Authentication | Tracing
# Friday, 15 May 2009

First you need to enable the CA to accept SAN requests by changing the registry:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

An nice description on how to enable SAN's on a MS CA can be found here.

http://support.microsoft.com/kb/931351/en-us

I used that as a base to request WebServer certificates with certreq, but I had to remove the EncipherOnly line and I changed the Exportable flag to true in the INF file:

[Version]
Signature="$Windows NT$

[NewRequest]
Subject = "CN=corpdc1.fabrikam.com"   
; must be the FQDN of domain controller
; EncipherOnly = FALSE
Exportable = TRUE         
; TRUE = Private key is exportable
KeyLength = 1024          
; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1               ; Key Exchange
KeyUsage = 0xA0          
; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC

; Omit entire section if CA is an enterprise CA
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

[RequestAttributes]
CertificateTemplate = WebServer
;Omit  line if CA is a stand-alone CA
SAN="dns=.fabrikam.com&dns=ldap.fabrikam.com&dns=localhost"

 

The complete INF file syntax used by certreq can be found here: http://technet.microsoft.com/en-us/library/cc736326(WS.10).aspx

EncipherOnly seems not to work in my 2008 environment or some other flags made that invalid.

 

In addition on creating the request, I specified the CA on the certreq commandline:

certreq -new request.inf certnew.req
certreq -config mycaserver\myca -submit certnew.req certnew.cer

the last line outputs the requestid needed for the next certreq command. Then, on the ca, issue the certificate if it is not automatically issued (depends on the template used).
after that you can retrieve & accept the the certificate:

certreq -config mycaserver\myca -retrieve myidreturendfromsubmitcommand certnew.cer
certreq -accept certnew.cer

After that, you have a certificate with multiple SAN's in your computers machine store (we specified MachineKeySet) which can be used in IIS.


Just to mention:

It's easy to add multiple Websites to IIS using hostheaders, but if you want to use SSL on those sites you have to add the SSL binding. The easiest i found was using the commandline. the commands depend on the version of your IIS.

IIS6:

cscript.exe c:\inetpub\adminscripts\adsutil.vbs set /w3svc/mysiteid/SecureBindings ":443:myhostheader"

The hostheader is pretty obvious, and the mysiteid can be found when you click on the WebSites node in the IIS manager (Its the Identifier column).

IIS7:

appcmd set site /site.name:"mysite" /+bindings.[protocol='https',bindingInformation='*:443:myhostheader]
 

Friday, 15 May 2009 10:00:26 (Mitteleuropäische Sommerzeit, UTC+02:00)  #    -
Authentication | Certificates | IIS
# Friday, 20 February 2009
Basic Authenitcation is a - not so secure - method of authenticating users to a web server.
The username and password are sent in the HTTP request header with Base64 "encryption" which is as good as plain text.
However at some point you may have or may want to do just that, either because there is still no trust between organizations (believe me, the world is good :-)) or just because its too easy and other methods are way too hard to implement.
Now there you are, how do you add a header to a HttpRequest in plain c#?

Follow these steps:

  1. Generate the proxy using WSDL.EXE. Search MSDN on how to do that.
  2. Add this function to the partial class:

    protected override System.Net.WebRequest GetWebRequest(Uri uri)
    {
          HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(uri);
          if (PreAuthenticate)
          {
                NetworkCredential networkCredentials = Credentials.GetCredential(uri, "Basic");
                if (networkCredentials != null)
                {
                      byte[] credentialBuffer = new UTF8Encoding().GetBytes(networkCredentials.UserName +":" + networkCredentials.Password);
                      // Note the space after Basic
                      request.Headers["Authorization"] = "Basic " + Convert.ToBase64String(credentialBuffer);
                }
                else
                {
                      throw new ApplicationException("No network credentials");
                }
          }
          return request;
    }


  3. within the client using your proxy add the following:

    // these are NOT my real credentials
    NetworkCredential netCredential = new NetworkCredential("Elvis", "Graceland");
    Uri uri = new Uri(svc.Url);
    ICredentials credentials = netCredential.GetCredential(uri, "Basic");
    svc.Credentials = credentials;
    // set PreAuthenticate as it is checked !!!
    svc.PreAuthenticate = true;


Thats it....

Friday, 20 February 2009 14:48:23 (Mitteleuropäische Zeit, UTC+01:00)  #    -
C# | Webservices | Authentication
# Wednesday, 11 February 2009
There are two possible reasons for a BIND Problem in CLM
  1. Not in trusted sites
    If working with CLM, be sure to add the CLM website to your browsers Trusted Site list.
    Many problems like links that do not work, Active Directory (AD) Bind problems and of course ActiveX problems

  2. Service Principal names
    In order for Kerberos to work the SPN must be correctly set. Verify its setting by issuing SETSPN -l MYDOMAIN\serviceaccount where the serviceaccount is the account the IIS App Pool is running.
    It should contain something like
    HTTP/urltotheCLMserver
    If you are using WIndows 2008 you can check for duplicate SPNs by issuing setspn -X
Wednesday, 11 February 2009 14:20:08 (Mitteleuropäische Zeit, UTC+01:00)  #    -
Authentication | CLM
Archive
<2017 December>
SunMonTueWedThuFriSat
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
Any link on this site may lead to an external website that is not under my control and that external website might show an opinion that is not mine.

© Copyright 2017
Hannes Köhler
Sign In
Statistics
Total Posts: 39
This Year: 0
This Month: 0
This Week: 0
Comments: 1
All Content © 2017, Hannes Köhler
DasBlog theme 'Business' created by Christoph De Baene (delarou)