Meeting the InCommon Assurance profile criteria using Active Directory

[Brian Arkills <>]

I previously sent info and links about this. See the attached email--it has a bit of analysis/summary and some more links. Also I mention a Black Hat presentation earlier this year where Microsoft unveiled this work in the context of their efforts to address Pass the Hash and Pass the Ticket. I can dig up a URL for that presentation if folks want. There was a nice table in that presentation with info that I haven't seen anywhere else. And as I mentioned in the prior email there was a vague hope in the Black Hat presentation that maybe they'll back port some of this to prior OSes--although frankly, given the increased OS release cadence, I doubt it.

 

The LSASS memory credential work is something that via MVP channels I've been trying to get more detail about. In particular, I'd like to know how this work affects domain controllers, where the LSASS.exe process is arguably the most important process running on a DC. If I find out more, I'll share.

 

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Thursday, October 31, 2013 7:01 AM
To:
Subject: RE: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections

 

>> [ERIC] Even though I’ve responded to a couple of your comments here, I’m taking them overall as “topics for our internal conversation in prep for Friday” and not things to incorporate into the email response. Is that correct?

 

Eric, yes, that is correct -- just some overall topic ideas for conversation. 

 

For another topic consideration, I was just reading over Microsoft’s latest newsletter and they have some new information about Windows 8.1 which covers TLS/SSL, authentication, Bitlocker, credentials protection management, and identity and access control.  Many topics that are just what we are interested in regarding Microsoft.

 

Just one of the areas that was being discussed was admin management of AD DS servers, and there are some extra controls with Windows Server 2012 R2 + Windows 8.1 that could be considered improvements, which also might help understand the problems with prior versions.

 

Maybe it is unrealistic to expect the entire institution to convert to Server 2012/Windows 8.1 to use this feature, but maybe only the Silver users would need to be upgraded?

 

There is a lot more here talking about Schannel, LSASS, anti-malware, etc.

 

http://technet.microsoft.com/library/dn344918.aspx?ocid=wc-nl-secnews

What's Changed in Security Technologies in Windows 8.1

 

 

·         Protected Users security group

This new domain global group triggers new non-configurable protection on devices and host computers running Windows Server 2012 R2 Preview and Windows 8.1 Preview. The Protected Users group enables additional protections for domain controllers and domains in Windows Server 2012 R2 Preview domains. This greatly reduces the types of credentials available when users are signed in to computers on the network from a non-compromised computer.

Members of the Protected Users group are limited further by the following methods of authentication:

o    A member of the Protected Users group can only sign on using the Kerberos protocol. The account cannot authenticate using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8.1 Preview, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is a member of the Protected User group.

o    The Kerberos protocol will not use the weaker DES or RC4 encryption types in the preauthentication process. This means that the domain must be configured to support at least the AES cipher suite.

o    The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.

o    The default Kerberos Ticket Granting Tickets (TGTs) lifetime setting of four hours is configurable using Authentication Policies and Silos accessed through the Active Directory Administrative Center (ADAC). This means that when four hours has passed, the user must authenticate again.

For more information, see Protected Users Security Group.

 

From: [] On Behalf Of Eric Goodman
Sent: Wednesday, October 30, 2013 4:53 PM
To:
Subject: RE: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections

 

Fair enough, and thanks for the edits, David.

 

Jeffrey, I think I follow your arguments.

 

Although with AD DS, maybe if you are using Kerberos with approved algorithms, you would get a Kerberos key stored that would be compliant.  But ultimately, if AD DS just has the NT HASH

 

Hmm… that’s an interesting point. Not sure how AD Kerberos works if it doesn’t store Kerberos-style encrypted passwords. That is, MIT Kerberos stores actual encrypted (and therefore unencryptable) passwords, AD NT Hashes store password hashes (duh!) I’ve never read anywhere that AD stores encrypted passwords, so would expect that AD Kerberos uses the AD NT Hash instead of the password to encrypt the Kerberos tokens, but that’s simply speculation.

 

…” --- is a verification purpose the same as authentication?  Is 4.2.3.6.2 talking about authentication or synchronizing passwords? 

 

I assume verification is “in order to authenticate”, so yes, by my reading.

 

 

Even though I’ve responded to a couple of your comments here, I’m taking them overall as “topics for our internal conversation in prep for Friday” and not things to incorporate into the email response. Is that correct?

 

I’ll send a revised draft (including David’s edits) shortly.

 

--- Eric

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Wednesday, October 30, 2013 1:31 PM
To:
Subject: RE: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections

 

David & Eric,

 

Looks good on the changes.  I was reading through the IAP again in the “2 SCOPE” section and found some more possible insights.

 

Read this thinking of AD DS as an “alternate” system (not because of RSA key, PKI certificates, etc.) and you may see how the committee may be seeing that the “Authentication Secret authentication protocol” is fully in scope for all systems, including AD DS.

 

If other types of digital Credentials are used, the Authentication Secret requirements of this

IAP may not apply. In such cases the IdPO and its independent auditor must use

professional judgment in determining whether the other type of Credentials meet or exceed

the requirements in §4.2.3. Examples include:

• Authentication Secret-based systems that employ specialized client software for the

Authentication Secret authentication protocol and access management to the SP;

 

One other thing to consider for pointing out:  Under 4.2.5 AUTHENTICATION PROCESS, (resist, secure, mitigate), the challenge-response, Kerberos, and other such methods of authentication are covered, right?

 

Would it make sense to say that any “authentication process” problems related to 4.2.3 CREDENTIAL TECHNOLOGY should be “out of scope” for 4.2.3 since they would be covered by 4.2.5?

 

The problem for AD DS in the 4.2.3 sections relate to storing the authentication secrets regardless of the authentication protocol.  Although with AD DS, maybe if you are using Kerberos with approved algorithms, you would get a Kerberos key stored that would be compliant.  But ultimately, if AD DS just has the NT HASH, it will never meet the requirement which is why the cookbook suggests whole disk encryption such as Bitlocker to address the storage and protection of the secrets because Bitlocker uses AES which is approved.

 

But back to my point, if 4.2.3 is about credential technology and stuff like passing files of secrets around, then shouldn’t authentication be completely covered under 4.2.5 and not be mixed in with 4.2.3?  It seems like 4.2.3.6.3 is talking about a portion of the authentication process.  So what is 4.2.3.6.2 referring to when talking about “Whenever Authentication Secrets used by the IdP (or the IdP’s Verifier) are sent between services for verification purposes…” --- is a verification purpose the same as authentication?  Is 4.2.3.6.2 talking about authentication or synchronizing passwords? 

 

This goes back to the original statement that the IdP uses the Username/Password transmitted over HTTPS / SSL / TLS, not the NT HASH, Kerberos Ticket, etc.

 

Then of course, there is still the argument that 4.2.3.6.2 is “should” whereas 4.2.3.6.1 is a “must”.

-Jeff C.

 

From: [] On Behalf Of David Walker
Sent: Wednesday, October 30, 2013 1:38 PM
To:
Subject: Re: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections

 

Eric,

Looks good.  I've suggested a few minor changes below, mostly to soften the notion that this is an official response, as opposed to some comments to jump start Friday's discussion.

David

On Wed, 2013-10-30 at 16:25 +0000, Eric Goodman wrote:

Morning AD-DS-AM folks!
Here’s my draft of a response to the comments below. Does this sufficiently capture our discussion and responses? Comments? Corrections? Additions? Wordsmithing?

 
--- Eric

AD DS workgroup's response to the comments by Scott Koranda and Tom Barton,

AD Silver Cookbook workgroup's thoughts on the comments by Scott Koranda and Tom Barton

We are responding to the following comments noted in the thread below:

1) That administrative accounts that exist in an AD DS store are in scope of 4.2.3.6.1, 4.2.3.4 and 4.2.8(.2). (In response to our interpretation of 4.2.3.6.1)

2) That calling out the "change my password page" is potentially confusing and unintentionally scope-limiting. (In response to our interpretation of 4.2.3.6.2)

3) That our restriction/categorization of the requirements of various Authentication Secrets is not in line with the IAP (Also in response to our interpretation of 4.2.3.6.2)

We are largely in agreement with comments (1) and (2). Our intent in each of these was to limit the scope of the AD configuration requirements to only address accounts which can be used to generate IdP assertions. Note that there is a minor but significant error in our text, in that the reference to the "change my password page" should

...is a small but significant...

have been headed with "e.g.", not "i.e." In this way, we meant the statement to broadly include your comment #2 as well. We are happy to remove the specific example, and will work on language to clarify that any system or account that can undermine IdP assertion generation is in scope.

The one further clarification that we would add is this:

If AD is NOT the IdP verifier, but only has provisioned copies of the password used by the IdP, then the security of the administrative accounts in the AD DS are still out of scope of IAP in this section. That is, only those admin accounts, etc. that are capable of changing the password copies used by the IdP are relevant.

I think it's a little broader than just changing passwords.  How about "...that are capable of affecting assertions issued by the IdP are relevant."

On comment number (3), we believe our original interpretation sufficiently addresses the concerns subsequently raised in the discussion below.

With the configuration we have specified, username and password are the only Authentication Secrets that can be used to generate authentication assertions from the IdP. Therefore, Kerberos traffic (which does not directly transmit username/password) and NTLM traffic (which does not directly transmit username/password) while containing Authentication Secrets (encrypted tickets, challenges and responses) does not contain Authentication Secrets that are used by the IdP. Again, our interpretation is that Authentication Secrets used by the IdP are in scope of the IAP, regardless of whether the use of those secrets are by IdP or “some non-IdP application to a verifier”. Authentication Secrets that are NOT used by the IdP are the only secrets we are declaring out of scope.

We will note that if Kerberos and in particular NTLM traffic is considered in scope, then we believe either AD systems will not be able to be used to house InCommon Silver-compliant credentials in any realistic deployment and we will therefore submit an Alternate Means proposal allowing the use of these protocols. The arguments for the Alternative Means statement would be largely identical to the arguments we’ve given in the interpretation and in the above paragraph, we’d just be changing from arguing that our configuration “meets the requirements” to it “is an acceptable alternate means to meet the requirement”.

The use of the word "realistic" seems to argue against an alternative means that would be comparable.  How about, "...then we believe that, in a literal reading of the IAP, AD systems cannot be used to house Silver-compliant credentials, because AD does not use Approved Algorithms."  We would, therefore, propose an Alternative Means statement allowing the use of other algorithms in specific situations."

 

--- Eric

 

 

 

 

 

-----Original Message-----

From: [] On Behalf Of Dunker, Mary

Sent: Wednesday, October 23, 2013 12:39 PM

To: ''

Subject: [AD-Assurance] FW: [aac] AD Assurance Cookbook: Interpretation Sections

 

AD Assurance Cookbook Working Group members,

 

On behalf of the InCommon Assurance Advisory Committee (AAC), I am forwarding (below) comments by Scott Koranda and Tom Barton regarding specific sections of the AD Assurance Cookbook. We look forward to further discussion with you during your conference call at noon on Friday, November 1, 2013.

 

Best regards,

Mary Dunker

Chair, InCommon Assurance Advisory Committee

 

-----------------------------------------------------------------

Mary Dunker

Director, Secure Enterprise Technology Initiatives Virginia Tech Information Technology

1700 Pratt Drive

Blacksburg, VA 24060

540-231-9327



--------------------------------------------------------------------

 

 

-----Original Message-----

From: [] On Behalf Of Tom Barton

Sent: Monday, October 14, 2013 12:30 PM

To:

Subject: Re: [aac] AD Assurance Cookbook: Interpretation Sections

 

Some responses to the issues Scott raised are below. -Tom

 

On 10/13/2013 11:04 AM, Scott Koranda wrote:

> Hi,

> 

>> Hi All,

>> 

>> As I mentioned on yesterday's AAC call, the AD Assurance Cookbook has

>> been released for open review, and the working group is looking for

>> our guidance on their interpretations of the specific sections. I've

>> included the link to the entire cookbook below as well as the specific wording they would like reviewed.

>> 

>> LINK: https://spaces.internet2.edu/display/InCAssurance/

>> InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook+-+DRAFT+20131002

>> #

>> InCommonSilverwithActiveDirectoryDomainServicesCookbook-DRAFT20131002

>> -SecuringAuthenticationTraffic

>> 

>> Thoughts?

>> 

>> Ann

>> 

>> 

>> 4.2.2. Interpretation of IAP requirement, Section 4.2.3.6.1 - Strong

>> Protection of Authentication Secrets (Second Sentence)

>> 

>> Note, this IAP requirement addresses both storage and transmission of

>> passwords, so is addressed under both the "Encrypting Passwords"

>> topic and the "Securing Authentication Traffic" sections.

>> 

>> This requirement applies when IdP Verifier passwords are provisioned

>> into an AD DS store, whether or not the AD DS store being provisioned

>> to is the actual IdP Verifier. Note that this requirement only

>> applies to passwords for accounts that are actually authenticated by

>> the IdP (non-IdP accounts that are "co located" in the AD DS have no such requirements).

> I think the statement "this requirement only applies to passwords for

> accounts that are actually authenticated by the IdP (non-IdP accounts

> that are "co-located" in the AD DS have no such requirements)" is too

> strong.

> 

> I would agree that non-administrative non-IdP co-located accounts have

> no such requirements, but any administrative account in the AD must be

> covered and subject to operational constraints in 4.2.3.4 and 4.2.8,

> since any compromise of an AD privileged account immediately escalates

> to compromising AD accounts that are authenticated by the IdP.

 

Right, although this section of the cookbook addresses 4.2.3.6.1 perhaps it should also account for 4.2.8.2, which it currently does not mention.

 

>> For example, if an MIT Kerberos system is used as the IdP Verifier,

>> but the passwords used by that Kerberos system are also provisioned

>> into an AD DS, the AD DS provisioning process is in scope and

>> therefore must use Protected Channels, even though it is not being

>> used as the IdP's Verifier. (Again, this only applies to passwords

>> for accounts that are actually authenticated by the

>> IdP)

> See above. It should apply to passwords for accounts that are actually

> authenticated by the IdP AND all administrative or privileged accounts

> that can be used to make any administrative changes to accounts that

> are authenticated by the IdP.

> 

>> 4.2.3. Interpretation of IAP Requirement, Section 4.2.3.6.2

>> - Strong Protection of Authentication Secrets

>> 

>> Authentication Secrets[1] in the context of this requirement is

>> interpreted to mean those secrets (passwords, Kerberos session keys,

>> NTLM challenge responses, etc.) that can be used to directly

>> authenticate to the IdP or to directly modify authentication

>> credentials (i.e., can be submitted directly to a change my password

>> page).

>> 

>> Another way of stating this is that the intent of 4.2.3.6.2 is only

>> to protect against risks that can attack the IdP’s direct

>> authentication to its Verifier; protection of non-IdP Authentication

>> Secrets that incidentally use the same Verifier as the IdP, such as

>> Windows/Kerberos Tickets used to authenticate a user to a domain (a

>> la ctrl-alt-del)[2], are not in scope of 4.2.3.6.2. These non-IdP

>> Authentication Secrets are addressed elsewhere in the spec, such as

>> in 4.2.3.6.3.

> I disagree.

> 

> 4.2.3.6.2 is clear:

> 

> "...for example, an IdP to a Verifier, or some non-IdP application to

> a Verifier".

> 

> The phrase "non-IdP application to a Verifier" clearly puts "non-IdP 

> Authentication Secrets that incidentally use the same Verifier as the

> IdP" in scope for 4.2.3.6.2.

> 

> I understand that by making this statement and arguing that

> 4.2.3.6.2 keeps in scope the AD traffic between MS Windows deployments

> and the AD server there are serious issues, but I see no other way to

> interpret 4.2.3.6.2 in version 1.2 of the spec.

> 

> I would appreciate hearing other input on this before I proceed

> further with the items below, since I believe the construction the AD

> Cookbook team is using to "thread the needle" here falls apart here if

> my interpretation stands.

 

When I read this section I understand "non-IdP authentication secrets" to mean those of credentials that are not in scope for the IAP (for which a definition is offered in the first paragraph of this cookbook section). I don't see any statement in cookbook section 4.2.3 that implies that a non-IdP app using AD as a verifier is exempt from 4.2.3.6.2 when handling an in-scope secret. Also the cookbook's recommendations in section 5.3.1 explicitly apply to non-IdP apps equally.

 

I read cookbook section 4.2.3's use of a "change my password" app to be a literal broadening of what it means to be in scope for the IAP, though a logical one. But I suppose it might also mislead a reader to think that no other non-IdP app is covered by 4.2.3.6.2. Perhaps a specific statement should be included explaining that non-IdP apps which handle in-scope secrets are also subject to 4.2.3.6.2 and those that use AD as a verifier are addressed in cookbook section 5.3.2.

 

Further, use of a "change my password" app in connection with in-scope secrets is covered under IAP 4.2.4.3. When IAP 4.2.4.3.1 is used for password changing, the password changing app is subject to 4.2.3.6.2. So I'm not sure that singling it out here is really helpful.

 

Back to defining what's in scope, the definition in this cookbook section appears to be: if it's used to authenticate to the IdP, or if it's used to authenticate to a change my password app. I think the definition of in-scope authentication secrets is not related solely to specific technologies. They are in scope if they meet a whole variety of criteria that underpin the design of the overall Silver implementation.

 

We might suggest editorial changes be made in cookbook section 4.2 to help ensure that readers understand what I think the authors intended.

 

> Thanks,

> 

> Scott

> 

>> [1] The term “Authentication Secret” is assumed here to include the

>> information in an authentication packet; e.g., in addition to actual

>> authentication credentials (username/password), the information

>> negotiating the initial exchange of a session key or the response to

>> an authentication challenge is an “Authentication Secret”.

>> 

>> [2] This assumes that the local Windows/Kerberos tickets cannot be

>> leveraged to authenticate the user to the IdP, such as a standard

>> webpage that prompts for entry of user credentials. If the IdP

>> supports mechanisms that allow the user to generate authentication

>> assertions based directly on the possession of local Windows/Kerberos

>> tickets (e.g., SPNEGO, GSSAPI), then the Windows/Kerberos tickets used in that interaction WOULD be in scope of this requirement.

>> 

>> 4.2.4. Interpretation of IAP Requirement, Section 4.2.3.6.3

>> - Strong Protection of Authentication Secrets

>> 

>> This section addresses all handling of IdP Verifier authentication

>> secrets, even if those authentication secrets are not used to

>> authenticate anyone to the IdP. Note that authentication secrets that

>> could be replayed to authenticate directly to the IdP are also

>> covered by section 4.2.3.6.2, which has stricter requirements around

>> transport encryption.

>> 

>> That is, assuming an IdP that requires manual entry of a

>> username/password:

>> 

>>    • applications (including non-IdP applications) that

>>    handle the username/ password would be covered by both

>>    sections 4.2.3.6.2 and 4.2.3.6.3.  • applications

>>    (including non-IdP applications) that handle non-IdP

>>    authentication secrets based on IdP passwords (e.g., LM,

>>    NTLMv1, NTLMv2 or MIT Kerberos authentication packets for

>>    Silver IAQ users) would be covered only by section

>>    4.2.3.6.3

>> 

>> This section requires that policies and procedures are in place to

>> minimize the risk of this traffic being attacked in a way that would

>> subvert the security of IdP authentication events. While traffic

>> covered in this section may use Protected Channels to secure

>> authentication communications, an institution could also use other

>> mechanisms that are generally considered secure, even if they are not

>> Protected Channels.

>> 

>> For completeness, we note that protection of the password while it is

>> being locally processed within any application is also required, not

>> just protection while in transit to or from said application.

>> However, security of the information while being handled in a

>> transient fashion within a web application is beyond the scope of AD

>> DS configuration, so is not covered here.

>> 

>> 4.2.5. Interpretation of IAP Requirement, Section 4.2.5.1 - Resist

>> Replay Attack

>> 

>> This section refers specifically to traffic between the Subject and

>> the IdP, the IdP's Verifier, and/or a relying party as part of an IdP

>> authentication/ assertion event. All other traffic between the

>> Subject and the AD DS is beyond the scope of 4.2.5.2. Replay of

>> non-IdP authentication/assertion traffic is covered by sections

>> 4.2.3.6.2 and 4.2.3.6.3.

>> 

>> 4.2.6. Interpretation of IAP Requirement, Section 4.2.5.2 - Resist

>> Eavesdropper Attack

>> 

>> This section refers specifically to traffic between the Subject and

>> the IdP, the IdP's Verifier, and/or a relying party as part of an IdP

>> authentication/ assertion event. All other traffic between the

>> Subject and the AD DS is beyond the scope of 4.2.5.2. Eavesdropping

>> on non-IdP authentication/assertion traffic is covered by sections

>> 4.2.3.6.2 and 4.2.3.6.3.

>> 

>> 4.2.7. Interpretation of IAP Requirement, Section 4.2.8.2.1

>> - Network Security

>> 

>> "Network communications supporting IdMS operations" is interpreted to

>> mean communications between the actual software elements of the IDMS

>> operation or administrative traffic to the IDMS.

>> 

>> So the only AD DS-specific communications that would be in scope of

>> this requirement is intra-domain controller password replication.

>> (Note that provisioning of passwords into AD-DS is covered by

>> 4.2.3.6.1)

>> 

>> 

>> Ann West Assistant Director, InCommon Assurance and Community

>> Internet2 based at Michigan Tech office:

>> +1.906.487.1726

 

 

--- Begin Message ---

• From: Brian Arkills <>
• To: "" <>
• Subject: [AD-Assurance] Security features in Win8.1/WS2012R2
• Date: Mon, 23 Sep 2013 15:47:58 +0000
• Accept-language: en-US
• List-archive: <https://lists.incommon.org/sympa//arc/ad-assurance>
• List-id: <ad-assurance.incommon.org>

Here's a rundown of security features of interest coming with the WS2012R2 & Win8.1 release.

 

There's a Protected Users group, which in concert with the new Authentication Policies & Authentication Policy Silos features, enables some protections for users placed in this group:

 

-non-configurable protections

                Only Kerberos authentication, no ability to use NTLM (any version)

                Can't use DES or RC4 cipher suites (with Kerberos)

                4 hour TGT lifetime, no TGT renewal beyond

                Delegation forbidden

-Requires Windows 8.1 or WS2012R2 hosts & WS2012R2 domain/DCs

 

I mentioned the AuthN Policy/Silos. Those are fascinating, very similar to the old "Log On To"/Logon Workstations functionality in ADUC, but much more refined. In a nutshell, you can control what conditions are required in order to issue a Kerberos TGS. For example, if someone needs to access the "Finance" file share, in addition the usual stuff, you can require that the user logon request come from specific computers.

 

There are some LSASS hardening changes:

-Greatly reduced credential storage, such that across a bunch of the authN providers, credentials are no longer stored in memory. NTLM NT is the one hold out for the 3 types of users accounts listed (Microsoft Account, local user, domain user), unless the user is in the Protected Users group.

-Is a protected process such that non-protected processes can't read or inject.

 

There's a RDP RestrictedAdmin mode, which when configured, makes it such that you do not send your credentials over the wire to the RDP host & your logon token is not sent from that RDP host beyond.

 

You can explore material at http://technet.microsoft.com/library/hh831778.aspx. http://technet.microsoft.com/en-us/library/b92b04bc-95db-4732-b4ec-d35b3f639275 & http://technet.microsoft.com/en-us/library/c8836345-16bb-4dcc-8d2b-2b9b687456a3 have a good rundown of these features.

 

All of these features currently require Windows 8.1 and WS2012R2, but there was some hope for back ports to prior OSes at the end of a Black Hat presentation, with a TBD noted.

 

One other thing that I got reading between the lines of the Black Hat presentation (which focused on Pass the Ticket) is that Microsoft now considers NTLM a dead-end and is investing in features that don't leverage it.

 

-B

--- End Message ---