Renewing a expired certificate for a windows service bus is quite simple and the process is documented on msdn.

1. Stop-SBFarm on one of the nodes in the farm.
2. Install a new certificate on all Service Bus machines.
3. Set-SBCertificate – FarmCertificateThumbprint: Thumbprint of the new farm certificate – SkipKeyReEncryption
4. Update-SBHost cmdlet on all farm nodes.
5. Set-SBNamespace – Name namespace – PrimarySymmetricKey: service namespace key.
6.Call the Start-SBFarm cmdlet on one of the farm nodes.

However if the expired certificate has been deleted, you will run into issues running any command against the servicebus.

You will most likely receive the following error:

Certificate requested with thumbprint not found in the certificate store

I have seen various methods to resolve this by editing the registry and removing entries from SQL or re implementing your service bus, but a cleaner method is to simply restore your expired cert so it can be renewed.

1. Logon to your certificate authority
2. Find the issued certificate request by using the filter by using the certificate hash field and enter the thumbprint for the expired certificate. (note: thumbprint format uses spaces)
3. Select the certificate and export as binary and save as using the .cer file extension
4. Copy the .cer file to your service bus server
5. Import the certificate to the local store
6. Open the certificate store, and view the properties of the imported certificate. select the details tab and note down the serial number
7. Open command prompt as administrator and run the following: certutil -repairstore my “serialnumber”
8. Open powershell as administrator and run the following: get-sbfarm
9. Run the following start-sbfarm
10. You now can follow the procedure to renew a expired certificate

Here are some quick ADFS claim rules to get some specific requests. Remember to create the rules in order:

Case 1

Get the users group membership, including groups of groups and filter on for any group beginning with “Group-XX” then send as a role claim:

Rule 1

Rule 2

Case 2 (Update 13/09/2016 – Apologizes as i had uploaded the wrong rules initially, they are now correct)

Get the users Cross Forest Sec Group Membership (from TESTDOMAIN domain) Claim including groups of groups and filter on for any group beginning with “Group-XX” then send as a role claim.Before you set these rules remember to give the ADFS service account access to read foreign group membership of the domain you are quering as detailed here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/bda33eb9-ff6e-4e79-967d-f5430ade7310/give-access-to-account-to-view-member-of-attribute-on-foreign-security-principal?forum=winserverDS

• Replace TESTDOMAIN with the domain you are trying to query
• Replace Group-XX with the beginning of the group/s you are looking for, it’s a regex expression and you can also customize it to your needs. Alternatively you can remove “,  Value =~ “(?i)^Group-XX” ” and that will list all groups.

Rule 1

Rule 2:

Rule 3:

Rule 4:

Rule 5:

If you ever had the task to delete an OU which had Protected From Accidental Deletion enabled on all sub OU’s it can be a pain to manually unchecked for every single one.The easy fix is to run a command to turn off the feature for you on all sub OU’s. To do this we run the following powershell command, just replace the path to your OU and the server, leave the rest as it is:

While setting up gitlab with ADFS 3.0 we noticed there is a couple of gotchas you need to watch out for:

1. You need to set the NotBeforeSkew to something like 2 in ADFS
2. You need to trasform the transient identifier in ADFS
3. idp_cert_fingerprint is case sensitive and needs to be all in CAPS

To set it up follow the following instructions:

In gitlab you need to set the following config

• Replace the https://gitlab.com with your gitlab address
• Replace the https://adfs.com with your ADFS address
• REplace the https://gitlab.local with what ever you like
• Replace 35:FA:DD:CF:1E:8F:8B:E4:CA:E1:AE:2A:EF:70:95:D5:DC:5C:67:1B with the finger print of your signing certificate

For ADFS configure the following settings (Use the same address replacements as above):

Then Run the following command to set the skew in Powershell on the ADFS server:

In this article i will go over how to setup your ADFS 3.0 (available in Windows Server 2012 R2) server for OAUTH2 authentication.

A couple of things to note:

• This setup will work for both standalone and farm deployments (including using the WID database). This is because Microsoft build an OAuth Authorization Code Lookup Protocol so that if one server generates the token you can claim it from another in the farm (when using standalone artifact store): https://msdn.microsoft.com/en-us/library/dn409270.aspx
• Make sure you have a basic ADFS configured, there are plenty of guides like this one: https://technet.microsoft.com/en-GB/library/dn486820.aspx
• ADFS 3.0 does not support secrets or token encryption/decryption for OAUTH2
• While OAUTH2 is a standardized protocol i would not call Microsoft implementation a straight forward or standardized solution as there are some specifications.
• If you are using a self-singed certificate please make sure that:
  • The Service Communications Certificate has the option of (IsCA = $true), you can use the script from: https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6. This is a must in order for the TLS connection to be established.
• Make sure when you open the certificates in the AD FS console there are no errors
• I have used SHA 256 RSA Certificates and they work great.

!!!Warning!!! – If you use 512 Certificates you will experience issues on ADFS and with OAUTH2.0. You will need to disable TLS1.2 as it doesn’t support 512. You may see errors as show below in the AD FS Admin error log:

Event ID: 36874– TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

Here is some information you will need before we begin:

• ClientID : you can either come up with this or just use a generator like : https://www.guidgenerator.com/online-guid-generator.aspx
• Redirect URI : depending on the application you use and the domain this value will very so please check the application documentation (basically where the browser needs to be redirect after the authentication completes)
• Relaying party identifier: in most cases you will make this up, i recommend using the application domain eg.(https://www.myapp.com)
• The Claims: This would be what values you require to return back to the application, check with the application documentation.

After you are done you will need to make a note of the following things in order to configure your application:

• ClientID
• Redirect URI
• Auth Endpoint : this would be https://myadfs.com/adfs/oauth2/authorize (replace myadfs with whatever domain you have configured)
• Token Endpoint : this would be https://myadfs.com/adfs/oauth2/token (replace myadfs with whatever domain you have configured)
• The public key (the cert without the private key) of the root CA of your Service Communications Certificate. You can export this and add it to your application server Trusted Root Certification Authorities. This is need for a successful TLS communication.
• The public key (the cert without the private key) of your signing certificate. Usually you will need this in PEM or CRT format so you may need to convert it. This will be needed if you or the application you are using needs to verify the JWT token signature (strongly recommended).

Lets go into our ADFS server console and first configure our Relying Party Trust:

Now give our Relying Party Trust a meaningful name

Leave the next section blank as ADFS3 OAuth2 does not support encryption

Again we leave it blank as we don’t use SAML or WS

now we need to enter our Relaying party identifier

If you need multi factor then configure it if not skip it

Once that is done you can configure your Claims (Issuance Transform Rules) whatever they may be

Once done we need to configure our endpoints and we do this via Powershell with the following command:

We specify some of the variables you collected before hand and then give it a meaningful name

I also recommend you set the option “EnableJWT” to true on the Relying Party Trust you configured by running:

And that should be it, you should be able to now use the OAUTH2 function with your app.