Challenge: Changing the stored credentials on 64 instances of IIS every 30 days
I'm no web farmer, and don't have responsibility for any web farms. But here's an interesting challeng I've been asked about, second hand. Say you have 64 instances of IIS 6.0, running on 64 different machines. You've set the credentials in IIS to use a particular domain user, say "MyDomain\MyIISAdmin" But every 30 days the password will be changed, in line with corporate policy. The "solution" according to one company was "Well you'll just have to change it manually because microsoft have no solution to this." I don't buy that for a second! What would be your plan of attack? How would you crack this tough nut?
'Rik Hemsley' on Wed, 21 Nov 2007 22:30:23 GMT, sez: Change the corporate policy.
'lb' on Wed, 21 Nov 2007 22:41:46 GMT, sez: cheers Rik -- i think that could lead to a little more political wrangling than is needed to achieve an expedient result.
'Chris' on Wed, 21 Nov 2007 22:51:44 GMT, sez: Policies were built to have exceptions.
We have a similar situation. We have one account that does *not* expire every 30 (it expires every 180 instead). 2 people know the password. Solved.
'aaron' on Wed, 21 Nov 2007 22:56:07 GMT, sez: Hrmmmm...
If it's a domain user...you only have to change the password in one place, right? (ie the domain user account)
So, is the issue that each of the 64 systems need to have some stored credentials changed, or it's just a PITA to change the domain user's password every 30 days?
-aaron
'lb' on Wed, 21 Nov 2007 23:00:59 GMT, sez: @Aaron -- exactly, the domain user's password only needs to change once, but each of the 64 systems need to have some stored credentials changed.
i know the common 'solution' is to change the password less often, but in this particular case it was put to me that
'windows is clearly not an enterprise solution'
because in a unix environment this feature would be supported.
Hence i'd like to see what the real solution is, not the dodgy one ;-)
'Josh Bush' on Thu, 22 Nov 2007 00:33:34 GMT, sez: Where are the credentials stored? Is it a file or in the hive somewhere?
'Peter Seale' on Thu, 22 Nov 2007 00:56:20 GMT, sez: When problems like this arise, I ask the time-honored question: what does SharePoint do in this situation?
SharePoint (2007) has a timer service that (ideally) always runs on every machine, including front ends and application servers. If you have one server, great; it's running. If you have 50 servers, great; it's (ideally) running on all 50. And so on.
With this timer service, SharePoint is able to run various "timer jobs" at specified times. Usually these things finish within minutes (though you can speed up the process by running a console command to "flush out" all remaining jobs).
Anyway, the point I'm getting to is: if you have this timer job infrastructure set up already, all you have to do is send a "change password" timer job to every machine. Magic happens, and by the end, the passwords have changed.
I'll note that full-blown MOSS installations can have upwards of 8 service accounts, so this isn't just a "nice to have" feature.
Also, I don't know how the timer job service itself changes its own password while it's running. I don't know.
I'm probably oversimplifying the process, and I will point out that SharePoint has not been perfectly 100% successful doing this, but at least the feature is available, and has worked for me in the past.
If you want more info on THE SHAREPOINT WAY!, you can start at mega-admin-guru Joel Oleson's blog:
http://blogs.msdn.com/joelo/archive/2006/08/22/712945.aspx
Summary: it's not easy.
'Raj Chaudhuri' on Thu, 22 Nov 2007 03:05:35 GMT, sez: Here are two solutions, the first using WMI scripting, the second using raw Win32.
http://www.microsoft.com/technet/scriptcenter/guide/sas_ser_udva.mspx
http://msdn2.microsoft.com/en-us/library/ms675577.aspx
Both talk about generic services rather than IIS specifically, but the principles should apply equally well.
There is a guide for securely managing services and service accounts, available here:
http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/default.mspx
If at all possible, could you ask the challenger what the "UNIX way" of doing this is?
'Darren Gosbell' on Thu, 22 Nov 2007 03:08:56 GMT, sez: I'm not all that into farming myself :), but at a guess I would say that the account information might be stored in the IIS metabase. So changing one server and then using a script like this one to copy the change to the other 63 would be one approach http://technet2.microsoft.com/windowsserver/en/library/ba0e7001-3c41-40b9-b320-b6b6481c97251033.mspx?mfr=true
(I'm assuming that there is manual work to assign a new password anyway.)
'lb' on Thu, 22 Nov 2007 03:13:03 GMT, sez: top answer Raj!! that ought to do it!
thanks also PSeale -- i know who to turn to for ninja sharepoint skills.
'Duncan Smart' on Thu, 22 Nov 2007 07:10:10 GMT, sez: If you're talking about the identity of the AppPool - this is from one of our helper setup scripts (*.js). It creates an AppPool or alters its identity:
function CreateAppPool(serverName, appPoolName, userName, password)
{
// Connect to WMI, the IIS namespace, and the application pools node.
var locatorObj = new ActiveXObject("WbemScripting.SWbemLocator");
var providerObj = locatorObj.ConnectServer(serverName, "root/MicrosoftIISv2");
var pool;
try
{
pool = providerObj.Get("IIsApplicationPoolSetting='W3SVC/AppPools/" + appPoolName + "'");
WScript.Echo("'" + appPoolName + "' pool already existed - will update this pool");
}
catch(ex){}
if(pool == null)
{
WScript.Echo("Creating pool '" + appPoolName + "'");
pool = providerObj.Get("IIsApplicationPoolSetting").SpawnInstance_();
}
// Set values
pool.Name = "W3SVC/AppPools/" + appPoolName;
pool.AppPoolIdentityType = 3; //MD_APPPOOL_IDENTITY_TYPE_SPECIFICUSER
pool.WAMUserName = userName;
pool.WAMUserPass = password;
pool.Put_();
WScript.Echo("Complete.");
}
'Philip the Duck' on Thu, 22 Nov 2007 11:16:05 GMT, sez: Not sure what the problem is - if they're all on a single domain, as you stated, you only need a simple service (or even a script launched from Windows "Scheduled Tasks") running on one machine, which runs once a month and connects to each server, via ADSI if using script, or in a .NET language using System.DirectoryServices.DirectoryEntry ("IIS://" + machineName + "/W3SVC" + etc...), and changes the anonymous access name and/or password field (assuming you're authenticating via anonymous access).
This will work for IIS5, IIS6 and even IIS7 if you turn on "IIS 6 Management Compatibility" in Vista or Server 2008.
The machine running the password change service doesn't have to be one of the 64 servers, and doesn't even have to be on the same domain as long as you authenticate your ADSI / DirectoryServices connection with a domain account (e.g. could be your home XP box connected to the farm's LAN via VPN).
The 64 machine names and site names/numbers can be stored in a database, XML file, or even a plain text config/ini file, and Bob's your Auntie's husband...
It's not much different from the *nix approach, except there you'd probably do it with a Perl or Python script and use direct network paths to manipulate text config files (for Apache, or whatever web server you're using), and LDAP for authentication. I think. Functionally the same approach, though.
'Sam Bennet' on Fri, 23 Nov 2007 00:59:23 GMT, sez: Should be pretty easy with powershell as well, but not having servers to test on, I can not confirm this.
Good talk the other night, Leon. Nice to put a face and voice to the blog.
I have been an avid reader since before her mother's eyes.
Feel free to look me up if you are ever heading up this way.
All the best,
Sam
'lb' on Mon, 26 Nov 2007 09:22:36 GMT, sez: @Sam, re: "Feel free to look me up if you are ever heading up this way"
Up what way?
|