Comments for BPuhl's Blog http://imav8n.wordpress.com A little bit of everything without actually being much of anything Wed, 30 Sep 2009 19:36:40 +0000 http://wordpress.com/ hourly 1 Comment on unprotect a visio object by Brad Turner http://imav8n.wordpress.com/2009/09/11/unprotect-a-visio-object/#comment-565 Brad Turner Wed, 30 Sep 2009 19:36:40 +0000 http://imav8n.wordpress.com/2009/09/11/unprotect-a-visio-object/#comment-565 Ugh, I can't tell you how frustrating it was to not be able to move the AD Site object around on the page once it's placed. Thanks! Ugh, I can’t tell you how frustrating it was to not be able to move the AD Site object around on the page once it’s placed. Thanks!

]]> Comment on EASI ID (pt. 2) by Larry Aultman http://imav8n.wordpress.com/2009/08/07/easi-id-pt-2/#comment-564 Larry Aultman Wed, 30 Sep 2009 18:05:42 +0000 http://imav8n.wordpress.com/2009/08/07/easi-id-pt-2/#comment-564 I found your post to be most insightful considering problems faced by consultants. I wish that I had had this information three years ago when my company decided to commit to Live ID. It would have made a difference in our deployment and our business methods. What is needed is practical “use case” discussions. Documentation tends to be superficial which leads to dramatic mistakes in implementation. To further the federated concept there needs to be a DNS record that is universally accepted that indicates that a domain is federated. CNAME records could then (as Microsoft Live Custom Domains does) be used to discover the federating authorities that the domain may subscribe. For a concrete example within Microsoft universe, Live Custom Domains and OfficeLive don’t both treat the ownership equally. Live Custom Domains requires the owner demonstrate authority by creating the CNAME record or MX record in DNS while OfficeLive really nothing. But here is where the conflict becomes apparent in the Live ID system. A domain created in OfficeLive is “automatically” accepted by Live Services UNLESS is exists in Live Custom Domains in which case it is prevented from being created. That seems logical it should only exist ONCE in the Live Services system. But in fact Microsoft is keeping two different stores. OfficeLive checks against Live Custom Domains but Live Custom Domains does not check against OfficeLive before creating an identity. You can see from the different rationales why this is the case but the effect is that individuals are prevented from associating their email accounts to Live ID identities when the domain is “reserved” by Live Services. I completely agree that companies and organizations want control over their domain names and the use of those outside the company borders. Live Services issues an error to users who try and use an email address in a domain that is in either Live Custom Domains or OfficeLive. The error message is useless to the user as is its associated Help message content because it does not explain the nature of the error. The error is a legitimate business policy issue e.g., the company has not “issued” an account to the user under Live Custom Domains or OfficeLive and therefore the user is not allowed to create the account. As I said above having these insights earlier would have prevented many mistakes. So I offer a few facts and suggestions. To Live ID users: If your desire to use a service that accepts Live ID or any other federated identity (OpenID, etc.) is of personal nature outside your business then create an identity in the domain of the federated service. For example if using Live ID then create an identity at one of their domains such as Live.com and use that for all your personal sites. If you feel the need to separate personal business from social interest then create separate identities for these. I don’t think that we will ever get to the magical single-sign-on because of the divergent needs of individuals. We can however cut down on number of identities which significantly reduces our identity threat attack surface. To domain holders: You must ask yourself does my business need to allow individuals outside the corporate structure to have email addresses at the company? It very well may, take for example a home-based business franchise structure with independent representatives that market your products. Depending on how “close” you want to keep the business you might consider a second domain for corporate infrastructure that you can keep control of on an account level. In most cases the domain and the business are common. However if your domain represents your product and not your company then get a domain name for the company and put it on your business materials and market your product/domain in which case every person who uses your product/domain is marketing for you. Practical Usage of Live Services: 1. A Live ID once created will exist forever. The email name attached to a Live ID may be canceled. If it is canceled the Live ID still exists with all the attached content. That content will continue for a period time then will be deleted. The content is unreachable after the Live ID is canceled. Suggestion, only delete a Live ID after you have successfully backed-up all content. If you are a corporate administrator and the account is in a Live Custom or OfficeLive domain then change the password on the account and back-up the content before removing the account. 2. Setting up corporate Live Services domains. Fact, businesses are bought, sold, and have name changes as a matter of course so plan for it. The human response is to create this global account that will persist for a lifetime. That is well and good but doesn’t address reality. Even in the local bar establishment the owners decide to divorce, what happens to the domains that they may own. Suggestion, create a Live Services account for each domain that is a corporate domain. Further each domain should have a dedicated Administrator account that has no other function and is in the domain of the Live Services provider. For example, “domain.com” is added to a Live Custom Domain. The Administrator at the time the domain is being added should select to create a new identity in Live.com (not in the domain itself). This way the administrator account exists as a “superuser” account to the domain with an email address that is outside the account. It will always be accessible. This simply means that on your cheat-sheet (we all know everybody has one) you list your administrative account information for this new domain account. 3. Setting up corporate user accounts for Live domains. An important fact to understand that many miss, any user account established in Live Custom Domains or in OfficeLive “ARE” Live ID accounts. They don’t have to be added as Live ID accounts later, in fact you will get an error if you try to add the account to Live ID. Suggestion, administrators should add accounts to the corporate Live Services account only as needed. When adding the administrator must assign a password. I suggest that you use a password generator and check the box that forces the user to change the password on first use. Administrators should remove the accounts of individuals that leave the company and at least set the password to expire on a regular interval. I found your post to be most insightful considering problems faced by consultants. I wish that I had had this information three years ago when my company decided to commit to Live ID. It would have made a difference in our deployment and our business methods. What is needed is practical “use case” discussions. Documentation tends to be superficial which leads to dramatic mistakes in implementation.
To further the federated concept there needs to be a DNS record that is universally accepted that indicates that a domain is federated. CNAME records could then (as Microsoft Live Custom Domains does) be used to discover the federating authorities that the domain may subscribe.
For a concrete example within Microsoft universe, Live Custom Domains and OfficeLive don’t both treat the ownership equally. Live Custom Domains requires the owner demonstrate authority by creating the CNAME record or MX record in DNS while OfficeLive really nothing. But here is where the conflict becomes apparent in the Live ID system. A domain created in OfficeLive is “automatically” accepted by Live Services UNLESS is exists in Live Custom Domains in which case it is prevented from being created. That seems logical it should only exist ONCE in the Live Services system. But in fact Microsoft is keeping two different stores. OfficeLive checks against Live Custom Domains but Live Custom Domains does not check against OfficeLive before creating an identity. You can see from the different rationales why this is the case but the effect is that individuals are prevented from associating their email accounts to Live ID identities when the domain is “reserved” by Live Services.
I completely agree that companies and organizations want control over their domain names and the use of those outside the company borders. Live Services issues an error to users who try and use an email address in a domain that is in either Live Custom Domains or OfficeLive. The error message is useless to the user as is its associated Help message content because it does not explain the nature of the error. The error is a legitimate business policy issue e.g., the company has not “issued” an account to the user under Live Custom Domains or OfficeLive and therefore the user is not allowed to create the account.
As I said above having these insights earlier would have prevented many mistakes. So I offer a few facts and suggestions.
To Live ID users: If your desire to use a service that accepts Live ID or any other federated identity (OpenID, etc.) is of personal nature outside your business then create an identity in the domain of the federated service. For example if using Live ID then create an identity at one of their domains such as Live.com and use that for all your personal sites. If you feel the need to separate personal business from social interest then create separate identities for these. I don’t think that we will ever get to the magical single-sign-on because of the divergent needs of individuals. We can however cut down on number of identities which significantly reduces our identity threat attack surface.
To domain holders: You must ask yourself does my business need to allow individuals outside the corporate structure to have email addresses at the company? It very well may, take for example a home-based business franchise structure with independent representatives that market your products. Depending on how “close” you want to keep the business you might consider a second domain for corporate infrastructure that you can keep control of on an account level. In most cases the domain and the business are common. However if your domain represents your product and not your company then get a domain name for the company and put it on your business materials and market your product/domain in which case every person who uses your product/domain is marketing for you.
Practical Usage of Live Services:
1. A Live ID once created will exist forever. The email name attached to a Live ID may be canceled. If it is canceled the Live ID still exists with all the attached content. That content will continue for a period time then will be deleted. The content is unreachable after the Live ID is canceled.

Suggestion, only delete a Live ID after you have successfully backed-up all content. If you are a corporate administrator and the account is in a Live Custom or OfficeLive domain then change the password on the account and back-up the content before removing the account.
2. Setting up corporate Live Services domains. Fact, businesses are bought, sold, and have name changes as a matter of course so plan for it. The human response is to create this global account that will persist for a lifetime. That is well and good but doesn’t address reality. Even in the local bar establishment the owners decide to divorce, what happens to the domains that they may own.

Suggestion, create a Live Services account for each domain that is a corporate domain. Further each domain should have a dedicated Administrator account that has no other function and is in the domain of the Live Services provider. For example, “domain.com” is added to a Live Custom Domain. The Administrator at the time the domain is being added should select to create a new identity in Live.com (not in the domain itself). This way the administrator account exists as a “superuser” account to the domain with an email address that is outside the account. It will always be accessible. This simply means that on your cheat-sheet (we all know everybody has one) you list your administrative account information for this new domain account.
3. Setting up corporate user accounts for Live domains. An important fact to understand that many miss, any user account established in Live Custom Domains or in OfficeLive “ARE” Live ID accounts. They don’t have to be added as Live ID accounts later, in fact you will get an error if you try to add the account to Live ID.

Suggestion, administrators should add accounts to the corporate Live Services account only as needed. When adding the administrator must assign a password. I suggest that you use a password generator and check the box that forces the user to change the password on first use. Administrators should remove the accounts of individuals that leave the company and at least set the password to expire on a regular interval.

]]> Comment on Enabling Logging in ADFS by Travis Spencer http://imav8n.wordpress.com/2009/08/06/enabling-logging-in-adfs/#comment-504 Travis Spencer Fri, 18 Sep 2009 18:25:49 +0000 http://imav8n.wordpress.com/?p=290#comment-504 Grr! XML got snipped. If WP doesn't let this encoded stuff through, see http://msdn.microsoft.com/en-us/library/system.diagnostics.presentationtracesources.aspx. <configuration> <system.diagnostics> <sources> <source name="System.Windows.Media.Animation" switchName="SourceSwitch" > <listeners> <add name="textListener" /> </listeners> </source> <switches> <add name="SourceSwitch" value="All" /> </switches> <sharedListeners> <add name="textListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="Debug.txt" /> </sharedListeners> <trace autoflush="true" indentsize="4"></trace> </system.diagnostics> </configuration> Grr! XML got snipped. If WP doesn’t let this encoded stuff through, see http://msdn.microsoft.com/en-us/library/system.diagnostics.presentationtracesources.aspx.

<configuration>
<system.diagnostics>
<sources>
<source name="System.Windows.Media.Animation"
switchName="SourceSwitch" >
<listeners>
<add name="textListener" />
</listeners>
</source>
<switches>
<add name="SourceSwitch" value="All" />
</switches>
<sharedListeners>
<add name="textListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="Debug.txt" />
</sharedListeners>
<trace autoflush="true" indentsize="4"></trace>
</system.diagnostics>
</configuration>

]]> Comment on Enabling Logging in ADFS by Travis Spencer http://imav8n.wordpress.com/2009/08/06/enabling-logging-in-adfs/#comment-503 Travis Spencer Fri, 18 Sep 2009 18:23:28 +0000 http://imav8n.wordpress.com/?p=290#comment-503 Just use a different trace listener and the whole SvcTraceViewer thing's moot: Just use a different trace listener and the whole SvcTraceViewer thing’s moot:

]]> Comment on Enabling RSAT tools in Win7 by Will Owen http://imav8n.wordpress.com/2009/08/06/enabling-rsat-tools-in-win7/#comment-482 Will Owen Tue, 11 Aug 2009 14:15:52 +0000 http://imav8n.wordpress.com/2009/08/06/enabling-rsat-tools-in-win7/#comment-482 Totally Agree. Is a serious PITA. Totally Agree. Is a serious PITA.

]]> Comment on Enabling RSAT tools in Win7 by John Policelli http://imav8n.wordpress.com/2009/08/06/enabling-rsat-tools-in-win7/#comment-481 John Policelli Tue, 11 Aug 2009 12:46:30 +0000 http://imav8n.wordpress.com/2009/08/06/enabling-rsat-tools-in-win7/#comment-481 I agree that this is odd, and I'll add that it is very annoying. I typically use the ServerManagerCMD command-line tool to install the exact RSAT tools I need, or all tools with the following command: SERVERMANAGERCMD -install RSAT -allsubfeatures -restart I agree that this is odd, and I’ll add that it is very annoying. I typically use the ServerManagerCMD command-line tool to install the exact RSAT tools I need, or all tools with the following command: SERVERMANAGERCMD -install RSAT -allsubfeatures -restart

]]> Comment on EASI ID (pt 1.5) by EASI ID (pt. 2) « BPuhl’s Blog http://imav8n.wordpress.com/2009/03/26/easi-id-pt-15/#comment-477 EASI ID (pt. 2) « BPuhl’s Blog Sat, 08 Aug 2009 01:51:20 +0000 http://imav8n.wordpress.com/2009/03/26/easi-id-pt-15/#comment-477 [...] by BPuhl on August 7, 2009 Back in March, I posted EASI ID (pt 1.5), posting a question about who owns the rights to resources within a namespace, specifically email [...] [...] by BPuhl on August 7, 2009 Back in March, I posted EASI ID (pt 1.5), posting a question about who owns the rights to resources within a namespace, specifically email [...]

]]> Comment on EASI ID (pt 1.5) by Ariel Gordon http://imav8n.wordpress.com/2009/03/26/easi-id-pt-15/#comment-476 Ariel Gordon Fri, 07 Aug 2009 22:34:11 +0000 http://imav8n.wordpress.com/2009/03/26/easi-id-pt-15/#comment-476 Contoso owns the domain and any identifier in its realm. Email addresses bear a claim of employment. I.e. my @contoso.com address shows (with a certain level of certainty) that I work for Contoso. Using this address after I leave the company is akin to keeping distributing business cards with the address on it. Today, 99% websites leverage email providers' infrastructure for user authentication: you type your email address as a login then create a password that can be reset/resend via email, effectively handing the keys to the account to anyone who controls the mailboxn including the new guy--Jerry Smith in your example. Websites who implement authentication delegation (aka federation in the consumer sense of the term), could be informed by the IdP of user account deprovisionning and, as best practice, take action to close the account, prompt the user to create alternate credentials (if they have a fallback email address or phone #), etc. Thoughts? -Ariel. Contoso owns the domain and any identifier in its realm.
Email addresses bear a claim of employment. I.e. my @contoso.com address shows (with a certain level of certainty) that I work for Contoso. Using this address after I leave the company is akin to keeping distributing business cards with the address on it.

Today, 99% websites leverage email providers’ infrastructure for user authentication: you type your email address as a login then create a password that can be reset/resend via email, effectively handing the keys to the account to anyone who controls the mailboxn including the new guy–Jerry Smith in your example.

Websites who implement authentication delegation (aka federation in the consumer sense of the term), could be informed by the IdP of user account deprovisionning and, as best practice, take action to close the account, prompt the user to create alternate credentials (if they have a fallback email address or phone #), etc.

Thoughts?
-Ariel.

]]> Comment on Federation Services and Direct Access by Ariel Gordon http://imav8n.wordpress.com/2009/08/06/federation-services-and-direct-access/#comment-475 Ariel Gordon Fri, 07 Aug 2009 22:20:37 +0000 http://imav8n.wordpress.com/2009/08/06/federation-services-and-direct-access/#comment-475 Brian, If the apps relied on infocard logon, then you could setup your STS so that CS would try integrated auth first then fall back to U/P (or cert). This way you'd get a best and consistent user experience regardless of connectivity. Correct? -Ariel. Brian,
If the apps relied on infocard logon, then you could setup your STS so that CS would try integrated auth first then fall back to U/P (or cert). This way you’d get a best and consistent user experience regardless of connectivity. Correct?
-Ariel.

]]> Comment on Laura’s Rule for ADFS Troubleshooting by Odin http://imav8n.wordpress.com/2009/08/06/lauras-rule-for-adfs-troubleshooting/#comment-473 Odin Thu, 06 Aug 2009 20:11:59 +0000 http://imav8n.wordpress.com/2009/08/06/lauras-rule-for-adfs-troubleshooting/#comment-473 I Love that! I Love that!

]]>