Swedish Windows Security User Group

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

En aggressiv molnstrategi med tyngdpunkt på produkter från Microsoft ger träningskedjan SATS en bättre IT-miljö. Därmed underlättas företagets fortsatta expansion samtidigt som kunderna erbjuds bättre service.

Träningstrenden i Sverige håller i sig med oförminskad styrka. Ett tecken på detta är att antalet deltagare i utmanande lopp slår alla rekord – nästa års upplaga av Vasaloppet blev fulltecknat bara tio minuter efter att biljetterna släpptes i mars.

Det betyder också att det finns en god marknad för landets träningskedjor. Tätplatsen i Norden innehavs av SATS som har 108 träningscenter med 275.000 medlemmar. På nordisk nivå har SATS cirka 4.500 medarbetare som arbetar hel-eller deltid. En majoritet av dessa tillbringar sina arbetsdagar ute på träningscentren vilket kräver att IT-miljön ska fungera även i en decentraliserad verksamhet.

För att bättre kunna möta den utmaningen har SATS valt en molnlösning med Microsoft Office 365 och Microsoft CRM Online.

– Det handlar om alla delar i lösningen: mail, Sharepoint intranät, Lync och CRM. Alla medarbetare har snabb och smidig tillgång till mail och eftersom vi är spridda över flera orter och flera länder används Lync i stor utsträckning för den interna kommunikationen, säger Arvid Johansson, CIO på SATS.

Tidigare använde SATS samma produkter men lokalt och i egen drift. Den nya lösningen gör det möjligt för företaget att fokusera mer på att utveckla själva träningsverksamheten.

– Vi är en relativt liten organisation och vi har stort fokus på att driva utvecklingen framåt gentemot verksamheten. Basteknik är dyrt och vi jobbar för att tjänstefiera den bland annat genom att använda molntjänster. I och med att vi växer kan vi nu hantera det på ett mycket bättre sätt, det blir mycket lättare att öppna nya center.

Övergången till en molnbaserad IT-miljö har tagits emot väl av personalen, enligt Arvid Johansson.

– Skiftet att gå över till molnet är i sig inget som användarna egentligen ser annat än att systemen förhoppningsvis blir snabbare. På sikt innebär det att underhåll och uppgraderingar kommer att kunna ske per automatik.

 SATS har också vävt in den digitala tekniken i sina tjänster, 2012 lanserades introduktionsprogrammet SATS You^TM som är byggt på CRM Online. Genom denna får medlemmarna ett skräddarsytt träningsprogram på åtta veckor samt tillgång till en personlig tränare för att få hjälp att komma igång och anpassa programmet.  Träningen följs upp digitalt genom att medlemmar via webb eller mobilapp kan nå sitt träningsprogram samt titta på inspirerande videor och få tillgång till instruktioner och träningstips.

– Den personlige tränaren kan sköta hela dialogen med medlemmen via dator eller mobil och kunden har möjlighet att enkelt följa upp sin egen utveckling och sina framsteg, säger 
Arvid Johansson.  

Och den digitala utvecklingen kommer att fortsätta hos SATS.

– Det är definitivt en bana som vi kommer att följa och vi ser just nu på en massa olika möjligheter. De digitala tjänsterna inspirerar våra medlemmar att träna mer och gör att det trivs ännu bättre hos oss, säger Maja Thermaenius, Projektledare för utvecklingen hos SATS.

Kontaktperson

Arvid Johansson, CIO, SATS
Tel: 073-373 24 06
arvid.johansson@sats.se

Helen Hunt Jackson famously wrote, “By all lovely tokens September is here, with summer’s best of weather and autumn’s best of cheer.” I share Helen’s clear adoration for this time of year. As a sports fan, there are so many “lovely tokens” to enjoy. The baseball pennant race is heating up, college and pro football are underway, and various soccer leagues (real football to the rest of the world) continue. As a parent, there are the “lovely tokens” of my kids returning to school, which brings a reminder of summer’s passing and excitement for another year of learning, growing, and adjusting to a new routine. For me, the routine is set: the second Tuesday of the month is here and with it comes a round of “lovely tokens” to help protect our customers.

This month we released 13 bulletins–four Critical and nine Important–which addressed 47 unique CVEs in Microsoft Windows, Office, Internet Explorer and SharePoint. For those who need to prioritize their deployment planning, we recommend focusing on MS13-067, MS13-068, and MS13-069 first.

Our Bulletin Deployment Priority graph provides an overview of this month’s priority releases (click for larger view).

MS13-068 | Vulnerability in Microsoft Outlook Could Allow Remote Code Execution

In preparing for this month’s release, this is the first bulletin that caught my attention, and it likely caught yours as well. This privately reported issue could allow remote code execution if an email carrying a specially craft S/MIME certificate is viewed or previewed on an affected system. As detailed in the SRD Blog, creating S/MIME certificates is trivial, but creating the specific one in the precise manner needed to execute code will be difficult. Still, the possibility is there and that is why we listed this update as our highest priority for this month. We have not detected any active attacks here and if you have automatic updating enabled, you won’t need to take any action to be protected from this issue.

MS13-069 | Cumulative Security Update for Internet Explorer

This security update resolves 10 issues in all supported versions of Internet Explorer. All 10 were privately disclosed and we have not detected any active attacks for anything addressed by the bulletin. All CVEs are caused by the browser improperly accessing an object in memory. If you visit a specially crafted website with an affected system, an attacker could execute arbitrary code in the context of the current user. This security update is rated Critical for all versions of Internet Explorer.

MS13-067 | Vulnerabilities in Microsoft SharePoint Server Could Allow Remote Code Execution

This update for SharePoint Servers also addresses 10 issues, but here, only CVE-2013-1330 is Critical. While CVE-2013-3180, an Important-rated issue, was publicly disclosed, we have not detected any active attacks involving any of these issues. For the one Critical CVE here, an attacker could send specially crafted content to an affected server. After a failure to properly validate the input,
the attacker could then execute code on the system in the context of the W3WP service account. SharePoint Server 2013 is not affected by this Critical issue.

You can also watch the bulletin overview video below for a brief summary of today’s release.

 Our risk and impact graph shows an aggregate view of this month’s Severity and Exploitability Index (click for larger view).

Finally, we are revising Security Advisory 2755801 to provide the latest update for Adobe Flash Player in Internet Explorer. Full details about this update can be found in the advisory.

For more information about this month’s security updates, including the detailed view of the Exploit Index broken down by CVE, visit the Microsoft Bulletin Summary Web page.

Jonathan Ness and I will host the monthly bulletin webcast, scheduled for Wednesday, September 11, 2013, at 11 a.m. PDT. I invite you to register here and tune in to learn more about this month’s security bulletins and advisories.

For all the latest information, you can also follow the MSRC team on Twitter at @MSFTSecResponse.

I hope you find some lovely tokens to enjoy this month. Pumpkin spice can be a great additive this time of year; just remember not everything needs it. I look forward to hearing your questions in the webcast tomorrow.

Thanks,
Dustin Childs
Group Manager, Response Communications
Microsoft Trustworthy Computing

Helen Hunt Jackson famously wrote, “By all lovely tokens September is here, with summer’s best of weather and autumn’s best of cheer.” I share Helen’s clear adoration for this time of year. As a sports fan, there are so many “lovely tokens” to enjoy. The baseball pennant race is heating up, college and pro football are underway, and various soccer leagues (real football to the rest of the world) continue. As a parent, there are the “lovely tokens” of my kids returning to school, which brings a reminder of summer’s passing and excitement for another year of learning, growing, and adjusting to a new routine. For me, the routine is set: the second Tuesday of the month is here and with it comes a round of “lovely tokens” to help protect our customers.

This month we released 13 bulletins–four Critical and nine Important–which addressed 47 unique CVEs in Microsoft Windows, Office, Internet Explorer and SharePoint. For those who need to prioritize their deployment planning, we recommend focusing on MS13-067, MS13-068, and MS13-069 first.

Our Bulletin Deployment Priority graph provides an overview of this month’s priority releases (click for larger view).

MS13-068 | Vulnerability in Microsoft Outlook Could Allow Remote Code Execution

In preparing for this month’s release, this is the first bulletin that caught my attention, and it likely caught yours as well. This privately reported issue could allow remote code execution if an email carrying a specially craft S/MIME certificate is viewed or previewed on an affected system. As detailed in the SRD Blog, creating S/MIME certificates is trivial, but creating the specific one in the precise manner needed to execute code will be difficult. Still, the possibility is there and that is why we listed this update as our highest priority for this month. We have not detected any active attacks here and if you have automatic updating enabled, you won’t need to take any action to be protected from this issue.

MS13-069 | Cumulative Security Update for Internet Explorer

This security update resolves 10 issues in all supported versions of Internet Explorer. All 10 were privately disclosed and we have not detected any active attacks for anything addressed by the bulletin. All CVEs are caused by the browser improperly accessing an object in memory. If you visit a specially crafted website with an affected system, an attacker could execute arbitrary code in the context of the current user. This security update is rated Critical for all versions of Internet Explorer.

MS13-067 | Vulnerabilities in Microsoft SharePoint Server Could Allow Remote Code Execution

This update for SharePoint Servers also addresses 10 issues, but here, only CVE-2013-1330 is Critical. While CVE-2013-3180, an Important-rated issue, was publicly disclosed, we have not detected any active attacks involving any of these issues. For the one Critical CVE here, an attacker could send specially crafted content to an affected server. After a failure to properly validate the input,
the attacker could then execute code on the system in the context of the W3WP service account. SharePoint Server 2013 is not affected by this Critical issue.

Our risk and impact graph shows an aggregate view of this month’s Severity and Exploitability Index (click for larger view).

Finally, we are revising Security Advisory 2755801 to provide the latest update for Adobe Flash Player in Internet Explorer. Full details about this update can be found in the advisory.

For more information about this month’s security updates, including the detailed view of the Exploit Index broken down by CVE, visit the Microsoft Bulletin Summary Web page.

Jonathan Ness and I will host the monthly bulletin webcast, scheduled for Wednesday, September 11, 2013, at 11 a.m. PDT. I invite you to register here and tune in to learn more about this month’s security bulletins and advisories.

For all the latest information, you can also follow the MSRC team on Twitter at @MSFTSecResponse.

I hope you find some lovely tokens to enjoy this month. Pumpkin spice can be a great additive this time of year; just remember not everything needs it. I look forward to hearing your questions in the webcast tomorrow.

Thanks,
Dustin Childs
Group Manager, Response Communications
Microsoft Trustworthy Computing

In celebration of kids heading back to school, today we’re providing advance notification for the release of 14 bulletins, four Critical and 10 Important, for September 2013. The Critical updates address issues in Internet Explorer, Outlook, SharePoint and Windows. 

As always, we’ve scheduled the bulletin release for the second Tuesday of the month, Sept. 10, 2013, at approximately 10:00 a.m. PDT. Revisit this blog then for our analysis of the risk and impact, as well as our deployment guidance and a brief video overview of the month’s updates. Until then, please review the ANS summary page for more information that will help you prepare for bulletin testing and deployment. For all the latest information, you can also follow the MSRC team on Twitter at @MSFTSecResponse.

Thank you, 

Dustin Childs

Group Manager, Response Communications

Microsoft Trustworthy Computing

In celebration of kids heading back to school, today we’re providing advance notification for the release of 14 bulletins, four Critical and 10 Important, for September 2013. The Critical updates address issues in Internet Explorer, Outlook, SharePoint and Windows. 

As always, we’ve scheduled the bulletin release for the second Tuesday of the month, Sept. 10, 2013, at approximately 10:00 a.m. PDT. Revisit this blog then for our analysis of the risk and impact, as well as our deployment guidance and a brief video overview of the month’s updates. Until then, please review the ANS summary page for more information that will help you prepare for bulletin testing and deployment. For all the latest information, you can also follow the MSRC team on Twitter at @MSFTSecResponse.

Thank you, 

Dustin Childs

Group Manager, Response Communications

Microsoft Trustworthy Computing

More great tools by the ADFS team…

Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.

It is located on the SharePoint team blog and can be accessed here.

More great tools by the ADFS team…

Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.

It is located on the SharePoint team blog and can be accessed here.

More great tools by the ADFS team…

Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.

It is located on the SharePoint team blog and can be accessed here.

More great tools by the ADFS team…

Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.

It is located on the SharePoint team blog and can be accessed here.

More great tools by the ADFS team…

Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.

It is located on the SharePoint team blog and can be accessed here.

More great tools by the ADFS team…

Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.

It is located on the SharePoint team blog and can be accessed here.

====================================================================================== 

UPDATE:

I’m not going to remove this blog or the original blog on the web.config entries – but I do want to make note that these web.config files should not be modified directly anymore.  Please use the SetupSharePointADFS.vbs file to configure the MOSS applications for the SSO Provider.  The script eliminates the possiblility of typo’s, etc from these config files.  I have used the script many times and it works great.  If you open the help file included and go to the end – scenario 2 covers is the syntax you will use if you follow my other blog posts.

====================================================================================== 

It’s been a few months since I posted the steps for configuring the WebSSO provider in MOSS.  Recently, we have seen a spike in cases involving this configuration.  In almost all of these cases, the problem has been with the web.config files.  I’m going to try to highlight a couple of key points when setting this configuration up.  I’ve also made some minor changes to the original post to eliminate some confusion.

First item – there are three web.config files you will edit, the central admin file, the intranet file which uses Windows Integrated Authentication, and the extranet site web.config.   You will make the same changes to the central admin and intranet files.  I’m going to put the section needed here.  I recommend a copy/paste operation to notepad, change the fs-server to your actual server name, indent it how you like it, then modify the actual web.config files by copy/paste from your notepad file to the web.config file. 

In the intranet and the central admin web.config files add this section directly below the <authentication mode> section

<membership>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />

</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”AspNetWindowsTokenRoleProvider”>
<providers>
<remove name=”AspNetSqlRoleProvider” /> <add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
 </providers>
 </roleManager>

Now – on to the web.config file for the extranet.  Add these entries:

Add the following entry within the <configSections> node

<sectionGroup name=”system.web”>
<section name=”websso” type=”System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />
</sectionGroup>

Add the following entry to the <httpModules> node

<add name=”Identity Federation Services Application Authentication Module” type=”System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />

The ADFS authentication module should always be specified after the sharepoint SPRequest module in the in the <httpModules> section of the web.config file. It is safest to add it as the last entry in that section.

Add the following entry to the directly after the <authentication mode> node

<membership defaultProvider=”SingleSignOnMembershipProvider2″>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”SingleSignOnRoleProvider2″>
<providers>
<add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</roleManager>
<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://your_application</returnurl>
</urls>
<fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>

I’ve tried to clean up the trailing spaces and line it up with the technet documentation for my friends down in Houston 😉

Last – the latest issue we have seen is that we couldn’t add a user by their UPN address to the SharePoint site.  It turned out that an account store was not present on the FS-R.  Here is the explanation on why this matters.

<snip>

The people picker will look up a user based on the email name(note: not the UPN) by successively calling ADFS MembershipProvider methods. During invitation time, the ADFS membership provider will call web method GetTrustedRealmUri() to FS and return the appropriate results.

If the input names are of valid email syntax, in either of the following 3 cases, the people picker can successfully resolve the user (which means the GetTrustedRealmUri() web method will return TRUE):

1.       The user’s email suffix is accepted from one of the Federation trust partners.

2.       There is a Windows Trust setup in the Policy with the account partner and is set to accept all domain suffixes.

3.        There are account stores configured in the Trust Policy.

====================================================================================== 

UPDATE:

I’m not going to remove this blog or the original blog on the web.config entries – but I do want to make note that these web.config files should not be modified directly anymore.  Please use the SetupSharePointADFS.vbs file to configure the MOSS applications for the SSO Provider.  The script eliminates the possiblility of typo’s, etc from these config files.  I have used the script many times and it works great.  If you open the help file included and go to the end – scenario 2 covers is the syntax you will use if you follow my other blog posts.

====================================================================================== 

It’s been a few months since I posted the steps for configuring the WebSSO provider in MOSS.  Recently, we have seen a spike in cases involving this configuration.  In almost all of these cases, the problem has been with the web.config files.  I’m going to try to highlight a couple of key points when setting this configuration up.  I’ve also made some minor changes to the original post to eliminate some confusion.

First item – there are three web.config files you will edit, the central admin file, the intranet file which uses Windows Integrated Authentication, and the extranet site web.config.   You will make the same changes to the central admin and intranet files.  I’m going to put the section needed here.  I recommend a copy/paste operation to notepad, change the fs-server to your actual server name, indent it how you like it, then modify the actual web.config files by copy/paste from your notepad file to the web.config file. 

In the intranet and the central admin web.config files add this section directly below the <authentication mode> section

<membership>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />

</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”AspNetWindowsTokenRoleProvider”>
<providers>
<remove name=”AspNetSqlRoleProvider” /> <add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
 </providers>
 </roleManager>

Now – on to the web.config file for the extranet.  Add these entries:

Add the following entry within the <configSections> node

<sectionGroup name=”system.web”>
<section name=”websso” type=”System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />
</sectionGroup>

Add the following entry to the <httpModules> node

<add name=”Identity Federation Services Application Authentication Module” type=”System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />

The ADFS authentication module should always be specified after the sharepoint SPRequest module in the in the <httpModules> section of the web.config file. It is safest to add it as the last entry in that section.

Add the following entry to the directly after the <authentication mode> node

<membership defaultProvider=”SingleSignOnMembershipProvider2″>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”SingleSignOnRoleProvider2″>
<providers>
<add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</roleManager>
<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://your_application</returnurl>
</urls>
<fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>

I’ve tried to clean up the trailing spaces and line it up with the technet documentation for my friends down in Houston 😉

Last – the latest issue we have seen is that we couldn’t add a user by their UPN address to the SharePoint site.  It turned out that an account store was not present on the FS-R.  Here is the explanation on why this matters.

<snip>

The people picker will look up a user based on the email name(note: not the UPN) by successively calling ADFS MembershipProvider methods. During invitation time, the ADFS membership provider will call web method GetTrustedRealmUri() to FS and return the appropriate results.

If the input names are of valid email syntax, in either of the following 3 cases, the people picker can successfully resolve the user (which means the GetTrustedRealmUri() web method will return TRUE):

1.       The user’s email suffix is accepted from one of the Federation trust partners.

2.       There is a Windows Trust setup in the Policy with the account partner and is set to accept all domain suffixes.

3.        There are account stores configured in the Trust Policy.

====================================================================================== 

UPDATE:

I’m not going to remove this blog or the original blog on the web.config entries – but I do want to make note that these web.config files should not be modified directly anymore.  Please use the SetupSharePointADFS.vbs file to configure the MOSS applications for the SSO Provider.  The script eliminates the possiblility of typo’s, etc from these config files.  I have used the script many times and it works great.  If you open the help file included and go to the end – scenario 2 covers is the syntax you will use if you follow my other blog posts.

====================================================================================== 

It’s been a few months since I posted the steps for configuring the WebSSO provider in MOSS.  Recently, we have seen a spike in cases involving this configuration.  In almost all of these cases, the problem has been with the web.config files.  I’m going to try to highlight a couple of key points when setting this configuration up.  I’ve also made some minor changes to the original post to eliminate some confusion.

First item – there are three web.config files you will edit, the central admin file, the intranet file which uses Windows Integrated Authentication, and the extranet site web.config.   You will make the same changes to the central admin and intranet files.  I’m going to put the section needed here.  I recommend a copy/paste operation to notepad, change the fs-server to your actual server name, indent it how you like it, then modify the actual web.config files by copy/paste from your notepad file to the web.config file. 

In the intranet and the central admin web.config files add this section directly below the <authentication mode> section

<membership>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />

</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”AspNetWindowsTokenRoleProvider”>
<providers>
<remove name=”AspNetSqlRoleProvider” /> <add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
 </providers>
 </roleManager>

Now – on to the web.config file for the extranet.  Add these entries:

Add the following entry within the <configSections> node

<sectionGroup name=”system.web”>
<section name=”websso” type=”System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />
</sectionGroup>

Add the following entry to the <httpModules> node

<add name=”Identity Federation Services Application Authentication Module” type=”System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />

The ADFS authentication module should always be specified after the sharepoint SPRequest module in the in the <httpModules> section of the web.config file. It is safest to add it as the last entry in that section.

Add the following entry to the directly after the <authentication mode> node

<membership defaultProvider=”SingleSignOnMembershipProvider2″>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”SingleSignOnRoleProvider2″>
<providers>
<add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</roleManager>
<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://your_application</returnurl>
</urls>
<fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>

I’ve tried to clean up the trailing spaces and line it up with the technet documentation for my friends down in Houston 😉

Last – the latest issue we have seen is that we couldn’t add a user by their UPN address to the SharePoint site.  It turned out that an account store was not present on the FS-R.  Here is the explanation on why this matters.

<snip>

The people picker will look up a user based on the email name(note: not the UPN) by successively calling ADFS MembershipProvider methods. During invitation time, the ADFS membership provider will call web method GetTrustedRealmUri() to FS and return the appropriate results.

If the input names are of valid email syntax, in either of the following 3 cases, the people picker can successfully resolve the user (which means the GetTrustedRealmUri() web method will return TRUE):

1.       The user’s email suffix is accepted from one of the Federation trust partners.

2.       There is a Windows Trust setup in the Policy with the account partner and is set to accept all domain suffixes.

3.        There are account stores configured in the Trust Policy.

====================================================================================== 

UPDATE:

I’m not going to remove this blog or the original blog on the web.config entries – but I do want to make note that these web.config files should not be modified directly anymore.  Please use the SetupSharePointADFS.vbs file to configure the MOSS applications for the SSO Provider.  The script eliminates the possiblility of typo’s, etc from these config files.  I have used the script many times and it works great.  If you open the help file included and go to the end – scenario 2 covers is the syntax you will use if you follow my other blog posts.

====================================================================================== 

It’s been a few months since I posted the steps for configuring the WebSSO provider in MOSS.  Recently, we have seen a spike in cases involving this configuration.  In almost all of these cases, the problem has been with the web.config files.  I’m going to try to highlight a couple of key points when setting this configuration up.  I’ve also made some minor changes to the original post to eliminate some confusion.

First item – there are three web.config files you will edit, the central admin file, the intranet file which uses Windows Integrated Authentication, and the extranet site web.config.   You will make the same changes to the central admin and intranet files.  I’m going to put the section needed here.  I recommend a copy/paste operation to notepad, change the fs-server to your actual server name, indent it how you like it, then modify the actual web.config files by copy/paste from your notepad file to the web.config file. 

In the intranet and the central admin web.config files add this section directly below the <authentication mode> section

<membership>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />

</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”AspNetWindowsTokenRoleProvider”>
<providers>
<remove name=”AspNetSqlRoleProvider” /> <add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
 </providers>
 </roleManager>

Now – on to the web.config file for the extranet.  Add these entries:

Add the following entry within the <configSections> node

<sectionGroup name=”system.web”>
<section name=”websso” type=”System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />
</sectionGroup>

Add the following entry to the <httpModules> node

<add name=”Identity Federation Services Application Authentication Module” type=”System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />

The ADFS authentication module should always be specified after the sharepoint SPRequest module in the in the <httpModules> section of the web.config file. It is safest to add it as the last entry in that section.

Add the following entry to the directly after the <authentication mode> node

<membership defaultProvider=”SingleSignOnMembershipProvider2″>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”SingleSignOnRoleProvider2″>
<providers>
<add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</roleManager>
<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://your_application</returnurl>
</urls>
<fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>

I’ve tried to clean up the trailing spaces and line it up with the technet documentation for my friends down in Houston 😉

Last – the latest issue we have seen is that we couldn’t add a user by their UPN address to the SharePoint site.  It turned out that an account store was not present on the FS-R.  Here is the explanation on why this matters.

<snip>

The people picker will look up a user based on the email name(note: not the UPN) by successively calling ADFS MembershipProvider methods. During invitation time, the ADFS membership provider will call web method GetTrustedRealmUri() to FS and return the appropriate results.

If the input names are of valid email syntax, in either of the following 3 cases, the people picker can successfully resolve the user (which means the GetTrustedRealmUri() web method will return TRUE):

1.       The user’s email suffix is accepted from one of the Federation trust partners.

2.       There is a Windows Trust setup in the Policy with the account partner and is set to accept all domain suffixes.

3.        There are account stores configured in the Trust Policy.

====================================================================================== 

UPDATE:

I’m not going to remove this blog or the original blog on the web.config entries – but I do want to make note that these web.config files should not be modified directly anymore.  Please use the SetupSharePointADFS.vbs file to configure the MOSS applications for the SSO Provider.  The script eliminates the possiblility of typo’s, etc from these config files.  I have used the script many times and it works great.  If you open the help file included and go to the end – scenario 2 covers is the syntax you will use if you follow my other blog posts.

====================================================================================== 

It’s been a few months since I posted the steps for configuring the WebSSO provider in MOSS.  Recently, we have seen a spike in cases involving this configuration.  In almost all of these cases, the problem has been with the web.config files.  I’m going to try to highlight a couple of key points when setting this configuration up.  I’ve also made some minor changes to the original post to eliminate some confusion.

First item – there are three web.config files you will edit, the central admin file, the intranet file which uses Windows Integrated Authentication, and the extranet site web.config.   You will make the same changes to the central admin and intranet files.  I’m going to put the section needed here.  I recommend a copy/paste operation to notepad, change the fs-server to your actual server name, indent it how you like it, then modify the actual web.config files by copy/paste from your notepad file to the web.config file. 

In the intranet and the central admin web.config files add this section directly below the <authentication mode> section

<membership>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />

</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”AspNetWindowsTokenRoleProvider”>
<providers>
<remove name=”AspNetSqlRoleProvider” /> <add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
 </providers>
 </roleManager>

Now – on to the web.config file for the extranet.  Add these entries:

Add the following entry within the <configSections> node

<sectionGroup name=”system.web”>
<section name=”websso” type=”System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />
</sectionGroup>

Add the following entry to the <httpModules> node

<add name=”Identity Federation Services Application Authentication Module” type=”System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” />

The ADFS authentication module should always be specified after the sharepoint SPRequest module in the in the <httpModules> section of the web.config file. It is safest to add it as the last entry in that section.

Add the following entry to the directly after the <authentication mode> node

<membership defaultProvider=”SingleSignOnMembershipProvider2″>
<providers>
<add name=”SingleSignOnMembershipProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”SingleSignOnRoleProvider2″>
<providers>
<add name=”SingleSignOnRoleProvider2″ type=”System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ fs=”https://fs-server/adfs/fs/federationserverservice.asmx” />
</providers>
</roleManager>
<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://your_application</returnurl>
</urls>
<fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>

I’ve tried to clean up the trailing spaces and line it up with the technet documentation for my friends down in Houston 😉

Last – the latest issue we have seen is that we couldn’t add a user by their UPN address to the SharePoint site.  It turned out that an account store was not present on the FS-R.  Here is the explanation on why this matters.

<snip>

The people picker will look up a user based on the email name(note: not the UPN) by successively calling ADFS MembershipProvider methods. During invitation time, the ADFS membership provider will call web method GetTrustedRealmUri() to FS and return the appropriate results.

If the input names are of valid email syntax, in either of the following 3 cases, the people picker can successfully resolve the user (which means the GetTrustedRealmUri() web method will return TRUE):

1.       The user’s email suffix is accepted from one of the Federation trust partners.

2.       There is a Windows Trust setup in the Policy with the account partner and is set to accept all domain suffixes.

3.        There are account stores configured in the Trust Policy.