Right so we had a odd problem come into us the other week.
The issue was that windows 7 client machines were randomly losing their domain trust, so when the users tried to logon to these machines they were presented with the error:
“The trust relationship between this workstation and the primary domain failed”
This generally means that the machine account password(s) presented to AD by the workstation or incorrect, as explined by KB162797
“The computer’s machine account has the incorrect role or its password has become mismatched with that of the domain database.”
We know that a whole load of different things can put a workstation into the bad password state, but the one we are concentrating on is System Restore.
What was happening was that users were or something was cutting the power to the machine, such as a hard reboot/power off, this was causing corruption on disk and putting the machine into start-up repair, but start-up repair wasn’t not able to fix the corruption so it checked for a Restore point it found. This restore point was before the recent machine account password change cause the machine to lose its domain trust when it came back up.
This was documented by Microsoft as a problem with XP pro machine, in KB295049
This is also a problem with windows 7, and can be reproduce by following these steps:
- Create a restore point on a working machine.
- Run nltest.exe /cdigest:MESSAGETOHASH /domain:domain.com, to see what the current hashes are.
- Run nltest.exe /sc_change_pwd:domain.com, to change the machine account password.
- Run nltest.exe /cdigest:MESSAGETOHASH /domain:domain.com, again to make sure the hashes/machine account password has changed.
- Restore the system to the restore created above.
When the system finishes and comes back up we get the Trust Relationship error.
Now if you log on locally and undo the restore, it fixes the problem and no more trust error.
We had noticed that the machine account for one of our exchange servers had been deleted. Due to this exchange had stopped working and could not be logged into using a domain account, after quite a bit of research we came to the conclusion that it was safe to pull exchange out of the domain and then re-join the machine back to the domain.
This fixed the problem with the missing machine account but exchange didn’t come back up and report some errors, which meant permission problems.
We checked the permissions of one of our other exchange servers, and add the machine account for the problem server to the same groups. As soon as the server picked up the new permission exchange start functioning again, we rebooted the server for it to pick up the new permissions.
IsoMaker is a simple program that allow you to create iso image files.
You create a new folder and copy the files and folders you want in the ISO image into the folder:
Now just drag the New folder on to the isoMaker window, it should fill the text box with the path to the folder:
Now just click the Save button, select the save directory and type a file name and click save:
Wait for the process to finish, it will tell you in the status bar at the bottom and you’re done:
It’s that simple.
Here is the link to the exe:
We had a question put through about setting up a files share and allow the external public users access without requiring credentials, although not a good idea due to security as anyone on the internet can potentially access the share and dump viruses and trojans on to it hence opening up an entry point that could easily be exploited, reduced security.
It was a requirement so we did a little research and the following is what we came up with:
- Right click on the folder you want to share, on the Share tab note hte Network Path
- Now go to start and search “Local Security Policy” and press enter
- Expand “Local Policies” and then Click Security Options
- Find the Policy: “Network access: Let Everyone permissions apply to anonymous users” and set the setting to “Enabled” and click OK
- Now find the Policy: “Network access: Shares that can be accessed anonymously” and enter the Network path you noted in step one into the text box and click OK
- Now open Command Prompt, you can search cmd in the Start search and press enter
- Type the following command and press enter: gpupdate /force
- Now you should be able access the share without having the need to enter credentials but if they try accessing other share they will be prompted with the login dialogue box
Again, we cannot emphasise enough how bad of an idea this is, unless you have a genuine requirement for it and reduce the risk as much as possible.
By allowing unrestricted access you are opening an entry point that could easily be used. huge amount of security issues, e.g.
We had a question about delegating read permissions to bitlocker recovery keys stored in active directory for standard users, they had followed the process outlined in the following article but hadn’t worked for them, we then tested the same process and it didn’t work for us either:
We then tried the DelegateBitLocker.vbs script in the following link: http://technet.microsoft.com/en-us/library/cc771778(v=ws.10).aspx#BKMK_AppendixA we edited the script so it would only apply to the computers OU.
‘ Connect to Discretional ACL (DACL) for domain object
Set objRootLDAP = GetObject(“LDAP://rootDSE”)
FROM: strPathToDomain = “LDAP://” & objRootLDAP.Get(“defaultNamingContext”) ‘ e.g. string dc=fabrikam,dc=com
TO: strPathToDomain = “LDAP://CN=Computer,DC=Fabrikam,DC=com”
Set objDomain = GetObject(strPathToDomain)
WScript.Echo “Accessing object: ” + objDomain.Get(“distinguishedName”)
Set objDescriptor = objDomain.Get(“ntSecurityDescriptor”)
Set objDacl = objDescriptor.DiscretionaryAcl
This showed that it gives the group in question read permissions to inherited object recovery information, instead of just the restricted attributes of the object, keep in mind this is exposing only read only attributes, we tried this using ldp-ace which also worked:
The process for calculating password expiry is simply the last set date + the limit in the domain policy. Therefore if you change the policy from say 1 year to six months, it will be re-calculated to expire a user’s password in six months from their last set date. Any accounts beyond that will automatically expire. Likewise if there has been no policy and you set a policy for 90 days. Those passwords that have been “set” longer than 90 days would expire.
More information on this and scripts to identify accounts that are about to expire can be found here:
Find out when your Password Expires:
If you are using fine grained password policies in Server 2008, this will be slightly different as the domain policy is not the ultimate controller of password expiry. Please take a look at the RSOP section of the following: http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx
For more information on Fine Grained Passwords take a look at the following:
If you are considering separate policy for students and staff, then Fine Grained Passwords is greatly improved in Windows 2012:
The following flow chart show a quick overview of what happens when a Password Age Policy is set and the scripts to detect expired users:
We had an interesting question posed to us about allowing standard users to launch and work with the admin tools provided by the MMC, and whether the MMC requires elevated privileges.
We found some interesting thing upon testing, firstly no MMC doesn’t require elevated privileges to run some no UAC prompt will pop for the standard user and they will be able to launch and work the tool although will not be able to make changes without extra permissions, we are just talking about an account that is just part of domain users group.
An UAC consent prompt will be shown if trying to open mmc.exe while logged in with an account that has admin privileges.
We also found that if the standard user was a part of the “Group Policy Creator Owners” and they tried launch mmc.exe then they would be presented with access denied and UAC asking for admin credentials.