Q
Problem solve Get help with specific problems with your technologies, process and projects.

Setting up dual administrative controls for tighter security

I work in a large corporation as a liaison between finance and IT. We have Active Directory in place worldwide. Corporate documentation on AD consists of mountains of intranet documents on the rollout and objectives, but they never talk about anything other than monitoring performance, replication and otherwise making sure it works from an IT perspective. What I want is a little finance/business-relevant functionality.

We have an application used to conduct very sensitive transactions. It can be set up to use Windows authentication...

to grant access, assuming that users have been made members of the appropriate global groups that have access to the network/database resources (group membership is controlled exclusively by a group manager within finance in this case). Using the features of Windows authentication is good because it reduces finance's need to know IT and maintain an IT infrastructure. Instead, we can piggyback on IT's engineered solution rather than having to support our own, for which we don't have either the expertise or the budget.

But there is one critical issue for us following our corporate security standards implemented through AD -- a single helpline person has the authority to reset passwords for user IDs. In the worst case, a malicious, knowledgeable helpline person could reset a user's password and then enter our sensitive finance system, posing as an authorized user. Finance can't tolerate a single administrative authority outside our organization with the ability to control access to our system in this manner (our back door). On the other hand, finance is at risk if that authority resides completely within finance, too, because that person would probably possess much more knowledge about our sensitive system and how to violate it.

What we want is dual administrative activities to take place when a user requests their password to be reset -- allow the helpline to reset the user password as per our corporate standard, but require a second, unrelated person to confirm the validity of the action from within finance for users of this particular system. The question is how. If somehow, a network agent were able to monitor members of the global group that grants access to our application and then, if a password change was made to any member, they'd be automatically removed from the global group, which only finance can administer (i.e., add them back to the group), that would be ideal. In that case, a password reset by the helpline would also require finance to restore membership to the group with access to the application (dual administrative control when a password reset takes place).

Is there any way that AD could be configured such that a password reset could trigger removal from certain sensitive network groups that the AD administrator would NOT have control over? This would allow for dual administration and less risk of an internal hacker accessing sensitive network resources. Is there another way that dual administration could be implemented when resetting a user's password? Would group policies help? Should we monitor event logs and send alerts that would run VB scripts to remove the member?

Yes, the administrator could reset the user's password. I know of no way to take out-of-the-box AD and make it remove this privilege for the administrator. (There may be some deep and dirty AD config in the ACLS, however, but an admin could change them back.) However, if the administrator does not know the user's password, and uses the reset function, he cannot reset the password back to what the user used. So the user, when she tries to log on next, will not be able to, and will have to contact the help desk to have her password reset. This activity, of course, should be investigated. Yes, users do forget their passwords; but, couple this with a strong audit policy in the event log, and event 627 "A user's password was changed" will be recorded. You can match these with user requests. In addition, you can set up EFS so that an administrator would have to access the files from the user's workstation in order to decrypt them.

When the reset password privilege is delegated to a help desk, even more interesting issues abound. We tend to hire and vet administrators and expect a little more of them, and pay them well. We believe they know the rules, and we watch these privileged persons a little more closely. Help desk personnel are often not paid well, have less education and turnover is rampant. Even if you solve all those issues for the help desk person in your case, you still should work on getting some monitoring (see the audit route above).

And, yes, your solution might work. You could script removal from a group after password reset. You could also make that a requirement, write a password reset script that first removes the user from a group, then resets the password. The help desk uses this instead of Active Directory Users and Computers.

I like the concept, too. It separates duties; that is, the help desk can reset a password if they remove a user from group. Finance can put a user in group. Neither can do both. There would have to be collaboration for a malicious act.

Still, a rogue admin or a help desk person (if the privileges aren't worked out correctly) can access the normal password reset functionality in Active Directory Users and Computers. A number of things can go wrong. Ideally, if files are that sensitive and the risk cannot be tolerated, you need to adapt some other method of authentication like a smart card or biometrics. With Windows 2000, certificate services come free. You would have to purchase the cards and/or readers, but the software is there. You would have to securely implement them; and, no -- once done, you do not have to make every user use a smart card, you can just use it for the finance group and you can require that the smart card, not the password, is used. If a smart card is lost or damaged, a new one can be issued. This can be done in a way in which only the user sees the PIN. Even if the card is lost, it cannot be used without the PIN. After a small number of PIN "guesses," the card self-destructs.

Let me know what you do, and how it works for you. Developing sound and secure business practices from mounds of technical information is not always easy.

Dig Deeper on User passwords and network permissions

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchWindowsServer

Close