BrokeBerry

Attack Computer Wiz

A Security & Technology Weblog
Showing posts with label Active Directory. Show all posts

In some cases users in an Active Directory environment may see repeated lockouts after a recent password change. This is commonly associated with forgetting their new password, forgetting that they are logged onto another machine or server somewhere, or their old credentials are cached.

If after you have rebooted the machine, checked domain logs to try to figure out where accounts may be logged in, deleted Temporary Internet Files and you are at your whits end, cached credentials may likely be your culprit.

On your affected machine, run the blow command and delete any cached credentials that appear. This would especially be relevant if you are using a Proxy server.

rundll32.exe keymgr.dll, KRShowKeyMgr


user Posted by Mike Wright

| More


Open an elevated Command Prompt and type the appropriate lines for your need.

Replace FQDN with the Fully Qualified Domain Name of your KMS server:


Windows 7, Windows 8, Windows 8.1, Server 2008/2008R2 and Server 2012/2012R2:

    
    
  1. CD \Windows\System32 
  2. cscript slmgr.vbs /skms FQDN 
  3. cscript slmgr.vbs /ato 

Office 2010 32 bit

    
    
  1. CD \Program Files (x86)\Microsoft Office\Office14 
  2. cscript ospp.vbs /sethst:FQDN 
  3. cscript ospp.vbs /act 
Office 2010 64 bit

    
    
  1. CD \Program Files\Microsoft Office\Office14 
  2. cscript ospp.vbs /sethst:FQDN 
  3. cscript ospp.vbs /act 
Office 2013 32 bit

    
    
  1. CD \Program Files (x86)\Microsoft Office\Office15 
  2. cscript ospp.vbs /sethst:FQDN 
  3. cscript ospp.vbs /act 

Office 2013 64 bit

    
    
  1. CD \Program Files\Microsoft Office\Office15 
  2. cscript ospp.vbs /sethst:FQDN 
  3. cscript ospp.vbs /act
If your product is still not activating, you may have KMS configuration issues. A good place to start looking for problems is to run the below command on the same machine that you ran the above commands. This will tell you when and what KMS server your client is trying to activate.

    
    
  1. cscript ospp.vbs /dhistoryacterr

user Posted by Mike Wright

| More


While trying to demote an existing Windows Server 2008 R2 Domain Controllers I ran into quite the headache. After running "dcpromo" and following the first few steps of the demotion it seems to start and run just fine. But within a few seconds I was promoted for credentials with the below "access is denied" message.


I searched and searched but was not able to find a good solution so finally I gave up and ran "dcpromo /forceremoval". I then did the metadata cleanup and moved on. I then tried to remove the old DC computer object from the Domain Controllers OU and I was denied access again. I scratched my head and realized that the object was protected. Could this whole problem be that simple!? The answer is YES, it was that simple.

On my next DC demotion I re-created the same errors. I cancelled the dcpromo, went into ADUC and unchecked the "Protect object from accidental deletion" box, ran dcpromo and and everything went smooth without error!


  

user Posted by Mike Wright

| More


The replacement for AdminPack.msi is called Remote Server Administration Tools or RSAT. In order to install and configure these tools on Windows 7 follow the below instructions.

  1. Download and Install the appropriate package from the below link, don't let the name AMD64fre fool you. It is not for AMD and it is not in French.   Download Link
  2. Click on Start > Control Panel > Programs.
  3. Under "Program Features" click on "Turn Windows Features on or off".
  4. Expand the "Remote Server Administration Tools".
  5. Now choose any or all of the tools that you wish to manage from this workstation and Click OK.
Now, after you click on the "Start" button you will see a new option called "Administration Tools". There you will find the specified tools that you enabled.

user Posted by Mike Wright

| More


Establishing an external domain trust has many benefits when separate domains need to share services and data. However the convenience of a domain trust comes at a great risk to the entities within each domain. When establishing a domain trust there is two options for defining the way that users from the trusted domain authenticate to the trusting domain.

The first method is called “Domain-wide authentication”. With this method users from the trusted domain are able to access servers, services, shares and files with normal NTFS and share permissions. In my opinion this places the trusting domain at risk of group nesting or permission creep.

The second method is my preferred method. “Selective authentication” takes a “deny all” approach explicitly blocking all access at the server level to all users who are not explicitly granted the “Allowed to authenticate” permission. With this method administrators must grant rights to each system they wish to allow access to in addition to the NTFS and share permissions. It is an extra level and security and may give your domain administrators a little ease when considering the domain trust risks.

To enable selective authentication there are a few prerequisites. The user preforming the action on the trusting domain must be a Domain Admin or an Enterprise Admin. The domain functional level must be set to a minimum of Windows 2003.

To configure selective authentication on an existing trust:

  1. Open the Active Directory Domains and Trusts snap-in.
  2. Right click the domain that you wish to configure and click ‘Properties’.
  3. Click on the ‘Trusts’ tab.
  4. Select the trust you wish to configure and click the ‘Properties’ button.
  5. Click the ‘Authentication’ Tab and then click the ‘Selective Authentication’ radio button. 
  6. Click ‘OK’.
To configure selective authentication during the creation of a new trust:
  1. Open the Active Directory Domains and Trusts snap-in.
  2. Right click the domain that you wish to configure and click ‘Properties’.
  3. Click on the ‘New Trust’ button.
  4. While you are walking through the New Trust Wizard you will be prompted for the authentication type. Select ‘Selective Authentication’ and finish the setup.
Take note, if you do not see the Selective Authentication option during the trust creation or you cannot select it from the 'Authentication' tab, it is most likely that the functional level of your domain is not set to 2003 or better.

The last step in this process is to create a Domain Local Group in which you wish to add users from the trusted domain. The users added to this group will be allowed to authenticate to sepcific computers/servers. After the group is created:
  1. Open the "Active Directory Users and Computers snap-in.
  2. Navigate the tree and locate the specific computer/server that you with to grant access to.
  3. Right click on the computer/server object and choose 'Properties'.
  4. Click on the 'Security' tab.
  5. Click the 'add' button and search and select the Domain Local Group that you have just created.
  6. Once back at the 'Security' tab screen, in the lower half, find the "Allowed to Authenticate' permission and check the 'Allow' box.
  7. Click "Apply'/'OK'.
At this point, any user that you have added to that Domain Local Group will be allowed to authenticate to any resource on that specific computer/server. You will need to repeat this process for every system that you wish to grant access to and you will still need to configure NTFS and share permissions accordingly.


Microsoft

user Posted by Mike Wright

| More


Normally if a user needed to access their exchange email account they would simply log into the domain, configure their email settings and read their email. Certain things make this seemingly simple task, not so simple. One of those would be an external trust or an external trust with “Selective Authentication” enabled.

When users from a trusted domain need to access exchange services in a trusting domain they will be prompted for username and password. Also anytime they close their email application, log off, or restart, they will have to go through the authentication process all over again.

There is a way to bind a trusted domain user account to an exchange user account in the trusting domain. And the method actually is quite simple. Before we begin let me make a few assumptions.

  • The trusted domain is the domain the user logs in to.
  • The trusting domain is the domain where the user has a user account and an exchange account.
  • You have access to Active Directory Users and Computers MMC.
  • You have exchange tools installed.
  1. Open Active Directory Users and Computers in the Trusting domain.
  2. Locate the user account you wish to modify.
  3. Right click the user account and choose “Properties”.
  4. Click on the “Security” tab and then click “Add”.
  5. Click the “Locations” button and choose the domain you want to connect to.
  6. Enter the name of the user account in the Trusted domain that you wish to grant access and click “OK”.
  7. In the “User Properties” window of the “Security” tab, select the user account you just added.
  8. In the “Permissions” list, check the Allow boxes for the Read Permissions, Full Mailbox Access, and Associated External Account.
  9. Click “OK
The user in the trusted domain should now be able to access the exchange email account, of their associated user account, in the Trusting domain. If you have enabled “Selective Authentication” in your trust configuration you may also need to apply the “Allowed to Authenticate” to the Exchange server object in ADUC also.

Microsoft KB278888

user Posted by Mike Wright

| More