I was working at the Geneva (Microsoft’s claims based access and federation technology; the next incarnation of ADFS) pod at TechEd this week and heard a good example of why such a technology is useful.
Suppose JW Secure has an internal website called http://paycheck for employees who want to view semi-monthly paystub information online. But as a cost-cutting measure, the company wants to outsource payroll processing to a company such as ADP. How to let employees continue to access the same information, with the same level of convenience, securely, while using existing ADP’s online services, without creating duplicate accounts or exposing non-essential infrastructure data externally? And let’s make it standards-based 😉
Geneva is a good approach. To accomplish this, JW Secure and ADP both setup a Geneva server. ADP’s Geneva server is configured to trust a limited set of claims from JW Secure’s Geneva server – for example, that a given token holder is in fact the named JW Secure employee (say, Dan Griffin).
Then, when user Dan Griffin opens http://paycheck from his desk, the internal server refers him to an external URL such as http://online.adp.com/jwsecure. The latter server determines that the user needs to be authenticated and refers Dan’s browser to ADP’s Geneva server. The latter server, based on the “jwsecure” in the referral URL, refers Dan’s browser back to JW Secure’s Geneva server.
So far, it’s just a chain of referrals, but here’s the magic. JW Secure’s Geneva server authenticates Dan using his internal Active Directory credentials (i.e., good old extensible Integrated Windows Authentication). Thus, authentication is seamless to Dan, and no shadow or duplicate accounts are required. The Geneva server then builds a SAML token for Dan, signs it with a key trusted by the ADP Geneva server, and refers Dan’s browser back to ADP.
Now, ADP’s Geneva server receives and validates Dan’s SAML token, determining if it trusts the claims made therein. Assuming it does, Dan views his paycheck on http://online.adp.com/jwsecure, having done nothing more than open his browser to http://paycheck (assuming he was already logged into his JW Secure domain account).
Check out the upcoming Tech Days 24-hour virtual event, sponsored by Microsoft. It’s a one-day marathon of technology presentations and demos, all via LiveMeeting (i.e., online). And it’s free! Should be interesting.
I submitted a demo proposal for our Biometrics Approval Workflow project, although I think I may have missed the deadline. We’ll see …
Check out the upcoming Tech Days 24-hour virtual event, sponsored by Microsoft. It’s a one-day marathon of technology presentations and demos, all via LiveMeeting (i.e., online). And it’s free! Should be interesting.I submitted a demo proposal for our Biometrics Approval Workflow project, although I think I may have missed the deadline. We’ll see …
Looking forward to TechEd! I’ll be staffing one of “The Learning Center” pods in the security area – will post an update as soon as I know which one.
TechEd is going to be in Los Angeles this year – the second week of May. How could I pass up an opportunity to not have to fly to the east coast for a great conference? I’ll be there!
Btw – rumor has it that there will be another PDC this year, its second year in a row, also in LA. I’m somewhat surprised that they’re doing PDC two years in a row, but the rationale is probably about building ISV momentum around the Windows 7 release. However, that doesn’t explain why they’re having TechEd and PDC in the same city. What about all of those folks in the northeast? Still, no complaints from me …
I got another shout out from the TechEd aggregator. It’s currently listed as the top entry at http://msdn.microsoft.com/en-us/events/teched/cc531163.aspx. Actually, they renamed my post to “Session notes and links on FCS/NAP”. Perhaps I should have chosen that title in the first place 😉
Just saw a cool talk for the very last session of the week: Security Compliance Management (http://technet.microsoft.com/en-us/library/cc677002.aspx). This is a free tool from Microsoft Solution Accelerators that integrates with the Desired Configuration Manager (DCM) feature of System Center Operations Manager (SCOM).
In summary, the download includes documentation and a set of locked-down security templates for Vista, XP, and Server 2008. The templates are XML-based, so you can modify them via the DCM GUI, or standard XML scripting/editing tools. The result is that the templates can be applied to machine groups, allowing reporting to be done on the inevitable state of compliance drift that happens to security configuration over time.
Still missing is auto-remediation. For example, the reporting mechanism can tell me how many (and which) machines are out of password policy, but they can’t automatically update that policy. I’m still dependent on Group Policy, which may be lagging or failing for some reason.
However, one of the audience members had a reasonable auto-remediation solution for now: within DCM, define the policy machine group to be based on the set of machines considered to be out of compliance base on a certain definition. For that set, advertise an update/patch – for example, an administrative script that SCOM will run on non-compliant machines to patch them up. It’s workable, and a clever idea, but not as “automatic” as customers will demand.
Still – SCM is a cool solution and worth checking out.
I did an interview with them two days ago, which will reported be posted in a week or so. Stay tuned!
I had the privilege of helping Frank Simorjay with his talk this morning. We had the … distinction of being first thing in the morning, last day of the conference, after the conference party the night before. Tough crowd! Actually, things went fine, and anyway I love a challenge. Here’s the official talk title:
SEC366 Get the Best Out of NAP with Microsoft Forefront Client Security: Better Protect Your Environment and Support Advanced Access Control to Your Network
Friday, June 13 8:30 AM – 9:45 AM, S220 E
Level: 300 – Advanced
The purpose of this session was to showcase the new Forefront/Network Access Protection Solution Accelerator (http://www.jwsecure.com/dan/2008/06/04/forefrontnap-solution-is-now-live/). This being a 300-level session, Frank invited me to provide commentary about the implementation. Here are my notes (modified slightly for this medium).
[Every technology domain has its own terminology and acronyms. Here’s a reference for this one.]
NPS = Network Policy Server (the NAP server)
SHA = System Health Agent (client-side NAP plug-in)
SHV = System Health Validator (server-side NAP plug-in)
SoH = Statement of Health (sent by the client)
FCS NAP Architecture
[Refer to the diagram about half-way down this page – http://technet.microsoft.com/en-us/library/cc512107(TechNet.10).aspx]
How does NAP implement sandboxing for non-compliant clients – in other words, how are unhealthy computers are kept separate from the healthy computers?
Suppose the NAP enforcement scenario is DHCP. In other words, client computers won’t be given an IP address on the corporate network unless they are deemed compliant by NAP. The first step is that the NAP agent on the client sends a Statement of Health along with the request to the DHCP server. In the diagram linked above, the client could be either of the laptop-shaped images on the left-hand side. The server in this picture, at the bottom of the larger oval, is playing two roles: DHCP server as well as Network Policy Server, or NPS.
The DHCP server receives the DHCP request from the client, extracts the Statement of Health, and relays it to the NPS to be evaluated. In this example, that’s just a question of one service talking to another service on the same server.
If the Statement of Health is considered to be compliant, then the DHCP server responds with an IP lease on the main, NAP-compliant, corporate network. If the Statement of Health is not compliant, then the DHCP server grants the client an IP lease on the restricted, non-compliant, sandbox network.
[A brief digression about deploying NAP in its DHCP scenario, since this came up a few times this week: be aware that there are some limitations inherent to DHCP. Namely, it’s not possible to implement server authentication and message integrity with the current standard-compliant DHCP. DHCP is an old protocol and wasn’t designed to do those things. Thus, organizations interested in NAP are wise to evaluate other NAP scenarios, such as 802.1x and IPsec, in which a higher security bar can be set.]
So how does the new FCS NAP solution play into this? It’s a question of what information is included in the Statement of Health, and how it’s evaluated by the NPS. FCS NAP consists primarily of two plug-ins: a System Health Agent (SHA) for the client and a System Health Validator (SHV) for the server (NPS).
[Refer to the diagram about half-way down this page – http://technet.microsoft.com/en-us/library/cc512113(TechNet.10).aspx]
The client SHA adds Forefront-related information to the SoH to be evaluated by the SHV. To the FCS NAP SHA, the SoH is effectively a bitmask. For example, one bit gets set only if the Forefront client is currently running (arrow #2 in the diagram referenced above), and another bit gets set only if the client’s virus signatures are up to date (arrows #1 and #3).
When the FCS NAP SHV receives that SoH bitmask (arrow #5), it evaluates each bit against the health policy configured by the administrator. For example, if the bit indicating whether Forefront is running is un-set, then the SHV checks whether the current policy indicates that Forefront must be running on healthy clients.
After evaluating each bit in the SoH bitmask in that way, there are generally two possible states the SHV can report to the NPS: the client is either healthy/compliant or un-healthy/non-compliant. In the latter case, for each non-compliant policy item, the SHV provides a message to explain to the user the reason, or reasons, why the machine is non-compliant. For example, “The Forefront client isn’t running,” and “The virus signatures are out of date,” etc. These messages are visible via built-in tools such as napstat.exe and netsh.exe.
There are two NAP configuration scenarios that affect how the SHV behaves: auto-remediation enabled and auto-remediation disabled.
Without auto-remediation enabled, the SHV again behaves as described above. That is, each aspect of non-compliance is addressed with a string explaining what’s wrong. However, the SHV must place different information into the SoH response when the client is non-compliant. The auto-remediation response information consist of two things:
First, different strings are used to distinguish between the scenarios in which the user is expected to take corrective action manually, versus the scenarios in which corrective action will be taken automatically by the SHA. The latter is what auto-remediation is all about.
Second, the auto-remediation SoH response must include instructions from the SHV to the SHA about what specific action to take. For example, if one of the required Forefront services isn’t running, and policy requires that it must be running for the client to be considered compliant, then the SHV will set the bit in the SoH bitmask instructing the SHA to attempt to automatically start the service.