Ken Schaefer

Speaking of Security Microsoft Australia/New Zealand's 2006 Security Summit/Interchange is coming up in Mar/April in a city near you! Charles Sterling has the details up on his blog, so I won't repeat everything here.

During the day, there will be two tracks, one each on developer and IT Pro related topics. During the evening there is a free, panel-discussion based event where you can interact with the speakers and other security professionals. Charles has a sample, intended agenda here. Given that there'll be people like Steve Riley, Mike Kleef and Andy Coates (etc, etc - too many names to list them all - read Charles' blog!) presenting, it looks like an event not to be missed.

Mitch's Solution #3Better Delegation Features in Windows
The last call from Mitch was for better delegation features in Windows. But the types of things that Mitch is asking for already exist. If you want to delegate permission to manage a file share, just give a user or group "Full Control" over that share. They can add/remove other users as required. You can do the same thing for a printer. You can perform similar actions within Active Directory (e.g. to delegate the ability to reset passwords for users, or add additional machines to an OU). There's even a handy Delegation of Authority wizard provided to automate the setting of the necessary permissions!

So what are the solutions?
I see solutions for the common user complaints that Mitch has outlined falling into a few categories. Some of these might seem overly complicated, but remember that (a) we need to ensure that whatever solution we implement allows for manageability of increased complexity (b) it offers benefits to end users without compromising the overall security and manageability of the network (c) it scales from small to large enterprises.

First Solution: Provisioning/Deprovisioning Systems
These types of systems typically share a number of features:

• They abstract the underlying permissions system
• They can connect to a number of underlying systems
• They feature workflow
• They permit delegation, whilst also maintaining a central repository of effective permissions that can be interrogated for reporting purposes (e.g. to determine a user's effective permissions)
• They can both enable access to systems, as well as remove access to systems.

An example of such a system would be Activate sold by the Innovation guys in NZ. It features a web based interface, workflow provided by Biztalk, and a central storage repository build on SQL Server. The user can request access to a resource, the request would be routed to the relevant delegated authority, who can grant it (again via a web interface). The system itself alters ACLs, creates/deletes mailboxes and so forth. Everything is recorded to that analysis can be performed.

My company Avanade also sells a solution, which is a bit more complex based around ADAM, MIIS, SQL Server, Biztalk. It can connect to disparate systems (such as Active Directory, SAP, Lotus Notes) to either enable access, or disable access. Since the system itself keeps track of what a user has access to, it can easily remove access to all systems a user has permissions to if a user leaves.

This system addresses the needs for getting access to resources

Second Solution: Identity Integration Systems
Products like Microsoft Identity Integration Server (MIIS) help avoid the problem of user's having to juggle multiple passwords/identities within an organization. It can connect to multiple individual systems via connectors and create/set the user's credentials in a synchronized manner. If/when a user needs to change their password, it's changed across all systems, leaving the user with just the one username/password. The systems are extensible, so it's possible to build a workflow on top of them (for example a self-service password reset system).

This system helps address the issue of having too many passwords/identities within an organisation.

Third Solution: Federated Identity Management across business boundaries
Mitch already touched upon standards such as SAML, WS-Security and FIM. These types of solutions allow a user in one business environment access to another business environment via a particular type of trust arrangement via the two. The authentication system (e.g. Active Directory) in one business is able to accept a credential token from the other business environment, without needing to see the user's password. This type of arrangement allows the user to have a single identity across multiple businesses, whilst allowing each business to maintain the effective permissions that the user should have.

In Mitch's last blog post, he alludes to something similar without realizing it, when he mentions the "web of trust". A bank might accept credentials from other organizations e.g. a driver's license or passport. However, what Mitch doesn't acknowledge is that it is still up to the bank to decide whether to permit a particular action (e.g. make a withdrawal). Just because the user is able to successfully authenticate using a foreign-generatewd token, doesn't mean that the bank automatically permits the action. The user might already be overdrawn on their account, and so it is still up to the bank to authorize the action. This is the same principle behind how FIM systems work. Mitch's example hasn't taken us any further down the road than where we've already come.

So, in conclusion (if you're still reading this!), both Mitch and myself realize that things can be improved in the world of end-user provisioning and access to resources. Where I think we differ is in the proposed solutions. I think Mitch's solutions concentrate too much on making things easier for the end-user without considering the overall needs of a secure network. I think the solutions that I've presented are the direction that most firms will be taking as they grapple with user access issues.

Mitch has written a long series of articles (1, 2, 3, 4) on "why network security sucks", and what his proposed solution is. It's difficult to summarise four long blog posts down to just a couple of lines, but I'm going to try anyway. My summary – Mitch is espousing the usual litany of user complaints:

• Too many identities need to be managed by the user in order to work effectively
• It's difficult and time consuming to get access to the resources that are required to do the job

I agree wholeheartedly that network security can definitely be improved to provide a better and smoother experience for the end user. At the moment it is too difficult, and too cumbersome in many organizations to get access to resources. What I disagree with are Mitch's proposed solutions. The solutions that Mitch proposes are:

• Make getting access work a little like Sharepoint. When you're denied access to something, allow the user to email the owner asking for access.
• Understanding that Authorization is more important than Authentication per se. If the user can supply a digitally signed authority to perform the action, then they should be able to perform the action
• Better support for delegation across the Windows platform, to make easier to support hierarchies of delegation (so as to allow a user to speak to their boss rather than having to speak to central IT to get access to something)

Mitch's Solution #1 The Sharepoint Solution
I'll leave aside the point that this solution already exists – you just email central IT asking for permission. Obviously this doesn't work for most users.

The real problem with Mitch's proposed solution is that it's too narrowly focused. It aims to make it easier for a user to gain access to a resource, but that's all. It's all about the individual user, and not the network as a whole.

The aim of giving users access to resources quickly is admirable. However network security is much more than that. We need to be able to determine, at any time, what the "state of play" is (i.e. determine what the effective permissions currently are), and we also need to be able to take away permissions. This is because network security is about ensuring that all authorised users have access to the resources they should have, and ensuring that all non-authorised users do *not* have access to those resources. So when an employee changes position we need to be able to work out which permissions they should keep, which additional ones they should be granted, and which ones should be taken away. And the more people you have changing permissions all over the network, the more difficult this task becomes.

This problem is summarized in general by the statement that complexity is the bane of security (I pinched that statement from Bruce Schneier's Secrets and Lies book, but it's also #8 on Microsoft's 10 Immutable Laws of Network Security). Complexity can come in many forms, for example: too many systems, too many processes or too many people making changes. Note that I didn't say "lots of people making changes" but rather "too many". When do we get from "lots of people making changes" to "too many people making changes"? When the resulting complexity is no longer manageable by the people charged with ensuring that the network is secure. Those people generally are the central IT unit. When they can no longer quickly determine whether everything is configured correctly and securely, then there's too much complexity and the risk that the network is no longer secure. How do we make it manageable? By using the correct tools, which I'll go into when I get to my section on solutions.

Mitch's Solution #2: The Signed XML solution
In Mitch's words:

The act of authenticating someones identity is certainly important, but when it boils down to it is the specific authority granted to an individual that counts. In fact a resource doesn't even really need to track the authority levels of individuals. Imagine a scenario where when trying to access a resource that you are challenged to provide evidence that you have the delegated authority to perform the operation requested. Rather than providing some authentication token, you (initially) provide a blob of XML which shows the delegation hierarchy from the resource to the system administrator to the business owner, to the mid-level manager and eventually down to you.

The only thing that the resource would need to know is who it delegated complete authority to in the first place (typically the installer). Then that person can sub-delegate as necessary without even informing the resource.

There are a few issues I see here. Firstly the user needs some method of managing all these bits of XML. Assuming we can overcome that, it seems ludicrous to me that an untrusted client can assert permissions to resources, rather than have the server consult a trusted list of ACLs maintained on the server itself.

Assuming we can get around that issue though, the biggest problem with Mitch's proposal is that it doesn't do anything to solve the problem. It presents exactly the same problems we have at the moment. Let's compare Mitch's proposal to what we have now:

In both cases the user needs to present some kind of token - whether it be "something the user knows" (a password), "something the user has" (smartcard/certificate, bank ATM card, signed XML), or "something the user is" (fingerprint).

In both cases the server needs to consult some kind of ACL (either in the traditional sense, or a revocation list to determine whether the signed XML is valid).

In both cases the user needs to get permission from someone who has the ability to grant that permission. In the traditional sense, the business owner would add the user to the file share's permission. Under Mitch's proposal the business owner would need to generate the XML.

The problem with Mitch's proposal is that unless there is some central store that records all the different bits of XML handed out, it's impossible for Central IT (or their security group) to actually known what the current effective permissions are for the enterprise, and that makes it very difficult to know whether we're in a secure configuration or not. And once we introduce the central store of permissions, we're right back where we began. We haven't actually advanced anywhere.

This discussion is continued in the next posting...

Based on various questions received on using IIS7, here are some tips.

Installation/Uninstallation
To install IIS you can use the Package Manager. Run the following at a command prompt:

If you are using Longhorn Server, you can also use the Server Manager tool.

To uninstall IIS 7.0 use the /up switch instead of /ip (up = uninstall package)

Management
To administer IIS use the webmgr.exe tool not inetmgr. Use InetMgr results in lots of errors when trying to do anything useful (like start the default website). Run the webmgr.exe tool using the /nommc switch for best results

Installing PHP
To install PHP, perform the following steps:

• Download and extract the PHP ZIP from www.php.net to c:\php
• Add c:\php to the Windows Path environment variable (at a command prompt type: Path=%Path%;c:\php)
• Rename c:\php.ini-recommended to c:\php.ini (and adjust any settings contained within that .ini file if required)
• Open WebMgr.exe and select the local webserver.
• Double-click "Handlers" under the "Server Components" heading
• Click New Server Module Handler
• Enter the following properties:
   Name: PHP
   Path: *.php
   Path Type: File
   Path Access: Script
   Request Type: enter the HTTP verbs you want to allow (GET, POST, HEAD etc)
  and then click Next
• On the next screen choose:
   Module: ISAPIModule
   Script Processor: c:\php\php5isapi.dll
  and then click Next, and then Finish
• Click the Home button to return the Web Server's properties home page
• Double-click ISAPI and CGI Restrictions under "Security"
• Click "New Restiction"
• Enter the following properties:
   ISAPI Dynamic Link Library (.dll): c:\php\php5isapi.dll
   Group ID: PHP
   Description: PHP
   Select (check) the "Allow extension to execute" checkbox
  and click OK
• Now create a sample PHP page (e.g. one containing <? phpinfo(); >) and save it in c:\inetpub\wwwroot\test.php
• Access your new page at http://localhost/test.php

Hope that helps you all. If there are additional questions, please feel free to contact me

David Lemphers has posted some thoughts on the MVP program. Since Clarke Scott has seen fit to replace his response, I'm going to put my $0.02 up as well. People who know me know that I don’t mince my words – I call a spade a spade. I apologise in advance if my bluntness causes offence. Please try to understand that I like to be direct and avoid "beating around the bush"

To summarise Dave's post first though (quotes are direct from Dave's blog):

• The MVP program is good overall. However there are some MVPs who "are not fully bearing their mantle as a Most Valuable Professional" and there are also some MVPs "that make the loudest blip on the radar, but don’t necessarily add value" who also get in.
• The solution "...is to continually 'churn' the MVP family". Dave believes that the year you have your MVP award gives you the opportunity to connect with product teams, gain valuable insights and gives you a platform to grow. After your one year is up, you don’t need that anymore.
• Dave looks forward to the day when "more and more people get to say those magic words... 'Oh yeah, I used to be an MVP, it's a tough racket'"

Whilst I have the greatest respect for Dave and the work he does, I think his solution sucks. You see what I mean about being direct :-)

Firstly, if there are people in the MVP program who are not carrying their weight, or who are just generating value-less noise, then the solution is to improve the awarding/selection/nomination process. As Dave pointed out in his post – he was one of the people who put in a successful nomination. It's incumbent upon the nominators to be more judicious in their nominations, and it's incumbent upon the MVP Program administration group to be more rigorous in their application of the criteria. Kicking everyone out of the program after some arbitrary period (one year) is throwing the baby out with the bathwater.

Secondly I strongly disagree that there should be different criteria for new entrants, and for people being re-awarded. MVPs should be awarded based on their contribution to the field/community, their technical expertise and their professionalism (someone who’s technically brilliant, but spends their time abusing less knowledgeable people should not be awarded IMHO). Being an MVP is an award for past action not a reward to be given to people who've performed well. As such the criteria should be the same for all. If it wasn’t gurus like Bill McCarthy and Mitch Denny wouldn't be MVPs, and that would be a travesty. The MVP program would become a "MVP for those that haven’t been MVPs before" program.

Lastly Dave might look forward to the day that people say "I used to be an MVP", but I don’t. I think Microsoft (and every other vendor) should encourage people to assist others with their technology, to push the boundaries of their products, and to provide feedback that helps improve the product. That’s what MVPs do, not people who "used to be MVPs"

Dave as posted a followup to his original post, though I’m not sure whether it’s a clarification of his original post (it doesn't look like it) or some additional thoughts. To respond to his points:

Lastly Dave might look forward to the day that people say "I used to be an MVP", but I don’t. I think Microsoft (and every other vendor) should encourage people to assist others with their technology, to push the boundaries of their products, and to provide feedback that helps improve the product. That’s what MVPs do, not people who "used to be MVPs"

Dave as posted a followup to his original post, though I’m not sure whether it’s a clarification of his original post (it doesn't look like it) or some additional thoughts. To respond to his points:

• The need for additional programs to recognize different types of work. I disagree. The MVP award can be used for any type of community work that meets the requisite criteria, whether that be user groups, newsgroups, running a website, or what-have-you. The additional stuff that MVPs get (access to product teams and so forth, presenting opportunities) are dependent on lots of other things already. They're not included as part of the formal MVP award, and as such can be given out at the discretion of the relevant MSFT owner depending on the skills/abilities of the MVP in question
• The use of the community to award MVPs. I disagree. The risk exists of cliques arising that continually re-award themselves. The ultimate decision on awarding MVPs needs to be based on a dispassionate, independent party applying transparent criteria. By all means accept nominations from all and sundry, but the final decision needs to rest in the hands of a neutral arbiter.

Well, that's enough venting for one day! Next post is on IIS7 in Longhorn Build 5270

Released quietly in early January was the Microsoft Exchange Server ActiveSync Web Administration Tool. If you're running Exchange 2003 SP2, and looking to implement the new "remote wipe" functionality this component is a required add-on for your server.

In addition to installing this tool, you'll need mobile devices that include the Messaging and Security Feature Pack (MSFP). These should become widely available in early March. If you already have an existing Windows Mobile 5 device, you will need to get a ROM upgrade from your manufacturer. For more information on the MSFP see Windows Mobile 5 MSFP

Now it seems like old news (having been available for two days now), but if you haven't heard Internet Explorer 7 Beta 2 is now available. More information on the beta is available on the IE Team Blog.