Systems Restore breaks domain trust

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”

<Picture>

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:

  1. Create a restore point on a working machine.
  2. Run nltest.exe /cdigest:MESSAGETOHASH /domain:domain.com, to see what the current hashes are.
  3. Run nltest.exe /sc_change_pwd:domain.com, to change the machine account password.
  4. Run nltest.exe /cdigest:MESSAGETOHASH /domain:domain.com, again to make sure the hashes/machine account password has changed.
  5. 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.

Thank You

Techtonis.

Exchange Server 2010 – Machine Account accidently deleted

Hello

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.

Thank You

Techtonis

IsoMaker – A Simple ISO Image Maker/Generator

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:
http://rapidshare.com/files/1367884714/isoMaker.zip

Thanks

Techtonis.

Windows file share with anonymous logon/access

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:

  1. Right click on the folder you want to share, on the Share tab note hte Network Path
  2. Now go to start and search “Local Security Policy” and press enter
  3. Expand “Local Policies” and then Click Security Options
  4. Find the Policy: “Network access: Let Everyone permissions apply to anonymous users” and set the setting to “Enabled” and click OK
  5. 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
  6. Now open Command Prompt, you can search cmd in the Start search and press enter
  7. Type the following command and press enter: gpupdate /force
  8. 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.
http://www.windowsecurity.com/articles/anatomy-nul-attack.html

Thank You

Techtonis

Delegating read permissions to bitlocker recovery keys held in Active Directory

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:

Thank You

Techtonis

Password Age Policies

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:

Thank You

Techtonis

Running Microsoft Management console (MMC) as a standard user without Admin privileges

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.

Techtonis.

CRM 4.0 Email Router not tracking email

We worked on a CRM 4.0 environment, where the Email router was not tracking incoming email, it turn out is was a problem with the configuration, we were also getting incoming status failure message.

To fix the Tracking issue the following settings were changed to correct the configuration:

  1. Open CRM 4.0 in the browser, click on the Tools button in the top menu.
  2. Then click on Options in the dropdown.
  3. Now click on Email tab.
  4. The “Track” setting was change from “E-mail message in response to CRM e-mail” to “All e-mail messages”

The following setting also changed:

  1. Open CRM 4.0 in the browser, click on the Settings button in the left menu.
  2. Then click on Business Management menu item.
  3. Now click on Queues on the right.
  4. Double Click on the Queue used to for tracking.
  5. Change the setting for “Convert to email activities” option  from “E-mail message in response to CRM e-mail” to “All email messages”

After setting the above two setting the tracking started working.

To resolve the incoming status failure the following commands were run to set the correct permission for access and impersonation:

  1. The following to allow CRM to access the user mailbox:
    Add-MailboxPermission “Mailbox” -User “username” -AccessRights FullAccess
  2. The following to allow CRM to impersonate the users mailbox:
    Add-ADPermission -Identity “Mailbox” -User “username” -extendedRight ms-Exch-EPI-May-Impersonate
  3. Finally the following to allow CRM to impersonate the exchange CAS server:
    Add-ADPermission -Identity “ClientAccessServer” -User “username” -ExtendedRights ms-Exch-EPI-Impersonation

Thanks.

Techtonis.

App-V Client Authentication Problem when you Install Live Essentials or Office 365 client components on the same windows client

When you install Live Essentials or Office 365 Single Sign in Assistant they install Security Support Providers of their own, “liveSSP” and “msoidSSP” respectively. These value are added to the “Security Packages” key in: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\”

Removing the “liveSSP” and/or the “msoidSSP” entry from the security packages key does temporary fix the problem, but if an update to office 365 or live essentials is applied then the SSP values are written back to the Security Package key and the issue occurs all over again.

Msoidssp is a SSP used to align the SSPI interface with the client so that the client can connect with the server in the secure channel, more information about this SSP in the following link: http://community.office365.com/en-us/w/office/534.aspx

In office 365, it’s already using the secure channel, msoidSSP was a second secure channel from the windows 7 client for it to drop back on to like a safety net if the it was unable to secure communicate using the normal method. Removing the registry should not impact the usage of office 365 services as long as it is able to communicate successfully without the need to drop back to the second SSP.

The bug fix should be available in App-V client 4.6 SP2.

App-V 4.6 SP2 Release notes, please read before updating to SP2: http://technet.microsoft.com/en-us/library/jj729866.aspx

Download Link: http://www.microsoft.com/en-us/download/details.aspx?id=35513

Thanks.

Techtonis.