Re: what is reset account?

No I don't think that policy value was available in Windows 2000. I believe the policy was added in K3, but the reg value works in 2K as well as NT.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Sasi wrote:
is this option also availabe in windows 2000? I don't have such option in my windows 2000 server security options.

"Joe Richards [MVP]" wrote:

1. Not if the person doing the rejoin doesn't have permissions in AD. This is a common config in large environments where very few people have rights.

2. http://technet2.microsoft.com/WindowsServer/en/library/0825816c-94e5-4a7f-be42-cbad6be4be501033.mspx?mfr=true

Also in GPOs, Security Settings | Local Policies | Security Options | Domain Member:Maximum machine account password age.



--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Sasi wrote:
Thank both of you guys for your explanations.
some questions:

1.you know that you can rejoin a machine to the domain WITHOUT resetting its account(provided that you have the permission to write some property on computer object);so whats the point in reseting its account?isn't it useless?

2.about that refresh interval(30 days for win2k+ and 7 days for win2k-),how can I change this default intervals?is it through a policy or AD should be modified (ADSI edit and so on)?


"Herb Martin" wrote:

"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message news:%23SoNTaQoGHA.4728@xxxxxxxxxxxxxxxxxxxxxxx
As for the relative insecurity, it entirely depends on the purpose of adding the computer to the group and what access(es) it grants. The issue comes in when you grant something that you want the computer to be able to see but not the users and the users have physical access or any
Ok, it doesn't really affect the cases where I would typical
want to use or recommend it.

Read access to shares that offer software intended to be
deployed based on computer account.

Such doesn't require perfect security, just practical control.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message news:%23SoNTaQoGHA.4728@xxxxxxxxxxxxxxxxxxxxxxx
As for the relative insecurity, it entirely depends on the purpose of adding the computer to the group and what access(es) it grants. The issue comes in when you grant something that you want the computer to be able to see but not the users and the users have physical access or any type of access rights that allow launching a process in localsystem or networkservice (or localservice if securing something local). Because at that point, the person can gain access to a process running in one of those contexts and will be running as the computer so will be able to see the information that was supposed to be locked off. In general this applies to users who are admins or power users but if someone ever got access to control the settings for a service or the ability to modify the info for a service then it is possible to escalate to the proper security context. Also obviously, anyone with physical access can do it if they want.

Securing things like GPOs has limited use when doing this. Overall, I am not a huge fan of group filtering, I have seen it go pretty bad on 3 different occasions. One of those occasions happened to me when I applied the GPO team's updates to the production domain and the ACL got wiped in the process (the poorly written script blew out midstream) thereby clearing the Group requirement which protected the GPO and thousands of workstations and servers around the world locked down to kiosk mode.

But anyway, say you set up a computer policy that all it does is set the password on the admin account. You feel it is safe because you locked it down so only the computers have access. There are two attack vectors: The first is to impersonate a computer, that is easily accomplished if power user or admin or you have physical access. The second is to set up a network sniffer and just pull the batch file off the wire or the GPO off the wire as it gets brought down to the PC. I used that once as a stepping stone when doing a security check for a company several years ago and within an hour had escalated myself all the way up to EA and sent an email from the Chief of Security's mail account. The email recommended that the consultant brought in to do a security check was amazing and should get double his stated rate because he was so helpful. :)

I thought about walking through what I did to compromise them but I think it would do more harm than good. It generally isn't good to explain in detail how someone can walk in off the street and compromise a corporate network. Security is just far too lax in most companies, even those that think or partially try to be secure including some very large major companies. Most folks will often think they are secure because they think, no one would ever do that, the consequences are too great if they get caught (say like tailing someone through a secured outside door to a building) but honestly, not everyone has the same value systems when looking at doing things and there are people who would not even think twice about stuff that most people would be far too scared to do because they think, someone MUST be watching. The scary fact is, someone usually isn't watching or is watching so poorly it is worthless. Secured doors are worthless unless they physically only allow one person to pass at a time or there is a security guard standing right there, anything else is insecure and can be breached. Once inside... how well does your network stand up? What rights do people have by default on workstations? In 90%+ of the companies... Admin. That can be used right there to cause a heap of trouble for most places. The larger the company, the more likely someone could walk into the building and get to a logged in working PC with very little to no issue or chance of being caught.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm



Herb Martin wrote:
Joe Richards [MVP] wrote:
Well it avoids the rejoin ASSUMING that the user who is doing the reset can force the client to do a password change. If the client isn't talking or the person involved has insufficient access at the client or the client is offline (which I guess is the same as not talking) the reset will only update the following attributes in AD (a password change)

dBCSPwd
unicodePwd
ntPwdHistory
pwdLastSet
supplementalCredentials
lmPwdHistory

and it will be up to some other process to sync the workstation with the account once the workstation can talk again (or the proper credentials are involved that will work with the current state of the client machine).
As usual, Joe, you teach me a quite a bit. Thanks (again and again).

[Also, I BELIEVE that I have seen one case where resetting the
computer account, along with repairing all other DNS problems etc,
STILL required a Win2000+ computer to be unjoined and rejoined to
the domain even though we TRIED our best to avoid that method.]

As Herb indicated, it was never necessary to delete and recreate. It wasn't critically important and usually still isn't if someone does though. While folks can add computers to groups, the relative insecurity of that still makes it something that isn't generally advised.
I would appreciate hearing more about this insecurity because there
are certainly cases where adding computers to groups is the
only practical choice, e.g.,

Assigning software to computers where the shares
and NTFS files are restricted so that only
certain subsets (i.e., Groups) of computers
can download that software

GP filtering when no better way is available to restrict
a GPO to a particular subset (group) of computers.


It is actually possible in an NT4 environment to add computer accounts to groups and ACLs, but I believe the native tools would choke if they tried but could display that just fine. Its use was limited though as Herb mentioned, kerberos didn't exist as a domain auth mechanism to allow the security relationship to be built up for standard Windows security functions across the network; though other third party products could use the membership. There was some product I had to help someone at a large financial company integrate back in around 96 or 97 or so and part of the requirement actually ended up being that we had to add the computer account to a group so I figured out how to do it.

joe
I suspected as much, but had never seen or heard of a way to do it.

.

Relevant Pages