In my last post (found here) I wrote about how to determine the account name of the local administrator account on a computer. Now that we know the account name, when did the password last change on that account?
Managing local accounts on computers (clients or servers) can be a hassle and one thing that makes auditing a little bit simpler is to find out how old the password for a local user on a machine is.
Administrating accounts on local computers (clients of servers) is not that common in a domain environment, but there is one account that often get discussed – the local administrator.
Some companies disable this account on machines, some set its password to a standard password and some randomize a password at deployment and keeps track of them in a database or similar. The thing is that sometimes, often in troubleshooting scenarios, it is really convenient to have the password for the local administrator account on a server at hand, but it can be tricky to keep track of which password to use on which server.
My friend Jimmy wrote a couple of post a while ago on non LVR (aka legacy) group members in Active Directory groups over at his blog.
You can find the his post on how to find non-LVR members here: http://jimmytheswede.blogspot.se/2013/06/non-lvr-groupmembers-how-to-find-them.html
The other day when I was facing a similar situation at a customer I wrote this PowerShell function that I used to list all non LVR members of a group:
Don Jones recently announced a tentative date for Winter Scripting Games on powershell.org. This time it will be a team-challenge with 2-6 contestants in each team and each team will be judged by a panel of expert judges.
I really like the way this event is developing giving the community new challenges and hopefully inspiring more people to start learning and using powershell. I would like to give a sincere thank you to everyone involved in hosting this great event!
Problem: Company.com has an exernal dns-record for service.company.com which should be resolved to an inernal IP by internal clients.
Let’s say that service.company.com resolves to 1.1.1.1 by the external DNS but when computers are connecting to this URL from inside the company network the internal DNS servers at ad.company.com needs to resolve service.company.com to 172.16.51.25.
Adding an entry to the hosts-file on each client computer to override service.company.com will not work when clients connect on exteral networks like from home or a coffeeshop.