Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My company is running a Windows based domain. The domain has a group policy of locking out a user after several failed log-in attempts, for 5 minutes.

Unfortunately, this account functions as a service account, and when the account locks out, a major service (Microsoft Team Foundation Server) ceases to function for those 5 minutes.

According to my IT manager, it is technically impossible, to remove the restriction for just one user account, though I suspect that his unwillingness (which I understand) to break policy is the real issue.

Could you please tell me if, and how to make an exception to the account policy? It seems to me unlikely that it is technically impossible to create exceptions to rules.

Disclaimer: I'm aware that having a service account that can log on to the system is a bad idea, but I unfortunately inherited this decision, and reversing it will take time.

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

As MichelZ, says, your manager is correct if you're on a 2003 domain. Though, regardless of that, I ideally wouldn't want to alter my policy for one single account, either. The real issue is that the service is attempting to log on with an incorrect password.

I'm posting this as an answer because the solution is to stop the issue altogether and figure out why a service is attempting to log in with the wrong password. If it's due to the password expiring then this can be sorted in AD Users and Computers rather than by reconfiguring the password policy:

enter image description here

This is standard practice for service accounts

share|improve this answer
    
I know I have to resolve the "bigger" issue. First things first, I have to make sure that the system is running and not freezing up and stopping 150 developers from working for 5 minutes (at a time). –  Assaf Stone May 22 '12 at 11:21
2  
@AssafStone I know what it's like to diagnose under pressure, but you need to remember that big sweeping policy (Both technical and procedural) changes are definitely never the first step. I know people like to push the business critical angle, but making hacky changes all the time nearly always leads to more issues and longer downtime in the long term. And those hacks never get put right, no matter the intentions of those doing them! But glad I could help, though. –  Dan May 22 '12 at 11:35
add comment

This is true for Windows Domains below 2008. Since Windows 2008, you can have different policies.

Have a look here: http://www.windowsecurity.com/articles/configuring-granular-password-settings-windows-server-2008-part-1.html

Edit:

Here's a link from Microsoft: http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx

share|improve this answer
    
Thanks for the link. That was the "proof" I needed. –  Assaf Stone May 22 '12 at 11:19
    
You're welcome. –  MichelZ May 22 '12 at 11:23
    
Hmmph. Unfortunately it turns out that our domain is 2003. Looks like the IT guy was right for a change... –  Assaf Stone May 23 '12 at 17:54
add comment

The real solution is a "Managed service account", when you use the regular accounts or even fine grained passwords and you set it to 'never expire' It's a security leak, with a managed service account the computer is changing the password itself and you don't have to keep track on it. and it's very secure!

Here's a link http://technet.microsoft.com/en-us/library/dd548356.aspx

share|improve this answer
    
Unfortunately the Managed Service Account doesn't help me with a 2003 server. –  Assaf Stone May 23 '12 at 17:55
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.