find and export user accounts with passwords set to never expire

c:\>Import-Module ActiveDirectory
c:\>Search-ADAccount -passwordneverexpires | export-csv c:\notexpires.csv

Advertisements

Windows 2008 Server R2 adprep\adprep32

Are you having trouble running ADPREP on your current 32-bit Domain Controller? Have you ran ADPREP multiple times on your Domain but still get an error stating you have not prepared your Domain yet?

Here is a change that gets even the most seasoned Admins. In Windows 2008 Server R2 there is a new ADPREP that needs to be run on a Domain Controller that are your FSMO role holder of the Schema Master role and run a 32-bit version of Windows Server. 

The Domain prep tool is called ADPREP32 which is located on in the \support\adprep.

The switches for the ADPREP32 are the same as the adprep. Here are the main switches used /FORESTPREP, /DOMAINPREP, and /RODCPREP.

Now adprep is still used when your current Domain Controller that holds the FSMO role of Schema Master role is running a 64-bit version of Windows Server. Actually the 64-bit version of ADPREP runs by default this is why you must know to run ADPREP32 on your 32-bit Domain Controller. 

Some background information on adprep:

ADPREP is a command line tool that comes with each version of Windows server.  ADPREP is used to extend the Active Directory schema to support the new features of Active Directory Services in the new Windows version.

There are a number of switches that need to be used with the ADPREP command depending on the version of Windows and the current Domain/Forest structure. 

ADPREP updates the Active Directory schema; updates security descriptors; modifies ACLs for Active Directory objects & SYSVOL; and sometimes creates new objects and containers.


Here are the Active Directory schema versions:

13=Windows 2000
30=windows 2003
31=Windows 2003 R2
44=Windows 2008
47=Windows 2008 R2

All about Permissions:NTFS and Share

Share vs. NTFS

Share permissions are the permissions you set for a folder when you share that folder. The share permissions determine the type of access others have to the shared folder across the network. There are three types of share permissions: Full Control, Change, and Read.

NTFS permissions determine the action users can take for a folder or file both across the network and locally. Unlike share permissions, NTFS permissions offer several other permissions besides Full Control, Change, and Read that can be set for groups or individually. The most restrictive permission applies when share and NTFS permissions conflict.

As you get deeper into creating shares and applying NTFS permissions to various assets, you’ll eventually run into a problem: What happens when you combine share and NTFS permissions?

For example, suppose you’ve shared a folder on a Windows Server 2012 system and you’ve created the share as a read-only share for the Everyone group, but the NTFS permissions for the folder are Full Control for the Everyone group. When conflicts like this arise between share and NTFS permissions, the most restrictive permission set wins out. So, in this example, the share’s read-only permission would win the day and users would be unable to make changes to files and folders inside the share.

Likewise, if the share permissions granted the Everyone group Full Control, but the NTFS permissions were Read, the NTFS permissions would win because they’re the most restrictive.

Keep in mind that NTFS vs. NTFS permissions are additive. So, if user A has been granted NTFS Read rights and a group to which user A belongs has been granted NTFS Modify rights, then user A gets both Read and Modify rights. However, once share permissions enter the equation, things are a bit different.

Another point to note: Share permissions are only enforced if the contents of the shared folder are accessed over the network. If a user manages to log in directly to a server and access the folder through the file system on the local server, only the NTFS permissions will apply.

Explicit vs. Inherited Permissions

Each permission that exists can be assigned one of two ways: explicitly or by inheritance. For this reason, permissions are referred to as explicit permissions and inherited permissions.

• Explicit permissions are permissions that are set by default when the object is created, or by user action.

• Inherited permissions are permissions that are given to an object because it is a child of a parent object.

Similar to the way rights are managed for groups of users, permissions are best managed for containers of objects. Objects within the container inherit all the access permissions in that container.

For example, you might explicitly give permissions to a folder named MyFolder. All subfolders created within MyFolder automatically inherit the permissions assigned to MyFolder.

In the example above, it is possible to stop subfolders from inheriting access permissions. To do this, you must explicitly clear a setting that causes the inheritance.

Allow vs. Deny Permissions

When establishing permissions, you need to specify whether the entry should have access (Allow) or not have access (not Allow) to the resource.

After permissions have been set, the LSASS (Local Security Authority) controls access to the resource. LSASS compares the SID (Security ID) that you placed on the ACL (Access Control List) with the SID placed on the security access token that is given to the user at logon. If the SID associated with the user is on the ACL, the LSASS must determine whether the access is set to Allow or Deny. The Allow and Deny permissions inherit down through the structure.

Use the Deny permission sparingly, because of the fact that restrictive permissions override lenient permissions. It is more common to clear all the Allow check box for a group, thereby removing the group from the ACL.

This has the same result, giving no access to the resource. “Not-Allow” access in this way is easier to troubleshoot, manage and configure. It is easy to forget that you have used the Deny option.

You deny permissions (using explicit Deny) only to a specific user when it is necessary to override permissions that are otherwise allowed for the group to which this user belongs.

Permission Precedence

Because of the fact that users have can have many different rights settings and objects can have many different permission settings, it is possible that conflicting permission settings might apply to a particular object and access method.

When this occurs, the system must engage in a process of resolving the various permissions to determine which ones should govern the access.

Here are some rules for resolving permissions conflicts:

1. “Deny” permissions generally take precedence over “allow” permissions.

2. Permissions applied directly to an object (explicit permissions) take precedence over permissions inherited from a parent (for example from a group).

3. Permissions inherited from near relatives take precedence over permissions inherited from distant predecessors. So permissions inherited from the object’s parent folder take precedence over permissions inherited from the object’s “grandparent” folder, and so on.

4. Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in terms of being “deny” or “allow”) are cumulative. So if a user is a member of two groups, one of which has an “allow” permission of “Read” and the other has an “allow” of “Write”, the user will have both read and write permission–depending on the other rules above, of course.

Although Deny permissions generally take precedence over allow permissions, this is not always the case. An explicit “allow” permission can take precedence over an inherited “deny” permission.

The hierarchy of precedence for the permissions can be summarized as follows, with the higher precedence permissions listed at the top of the list:

• Explicit Deny

• Explicit Allow

• Inherited Deny

• Inherited Allow

Get rid of second 169.254.x.x IPv4 address on Windows Server 2008 R2

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ there were two AdaptorGUIDs, but only one of them had any parameters.

I created the IPAutoConfigurationEnabled parameter for both these AdaptorGUIDs with a value of 0 as instructed and re-booted.

Here are the registry entries for the two AdaptorGUIDs:

Reboot and check.

Restoring the Default Domain and Default Domain Controller Policy in Windows Server 2008

It is Microsoft Best Practice to leave the Default Domain Policy alone – and create another Group Policy on domain level and define settings there. If you follow this Best Practice you surely have no problems when reverting your settings to the default. If you have changed the Default Domain Policy, you could run into pain what if you need to revert the settings you made?

C:\>dcgpofix /ignoreschema

Microsoft(R) Windows(R) Operating System Default Group Policy Restore Utility v5.1
Copyright (C) Microsoft Corporation. 1981-2003
Description: Recreates the Default Group Policy Objects (GPOs) for a domain
Syntax: DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

This utility can restore either or both the Default Domain Policy or the
Default Domain Controllers Policy to the state that exists immediately after
a clean install. You must be a domain administrator to perform this operation.

WARNING: YOU WILL LOSE ANY CHANGES YOU HAVE MADE TO THESE GPOs. THIS UTILITY IS INTENDED ONLY FOR DISASTER RECOVERY PURPOSES.

You are about to restore Default Domain policy  and Default domain Controller policy for the following domain

test.com

Do you want to continue: <Y/N>? y

WARNING: This operation will replace all ‘User Rights Assignments’ made in the chosen GPOs. This may render some server applications to fail. Do you want to continue: <Y/N>? y
The Default Domain Policy was restored successfully Note: Only the contents of the Default Domain Policy was restored. Group Policy links to this Group Policy Object were not altered.
By default, The Default Domain Policy is linked to the Domain.

The Default Domain Controller Policy was restored successfully Note: Only the contents of the Default Domain Controller Policy was restored. Group Policy links to this Group Policy Object were not altered. By default, The Default Domain Controller Policy is linked to the Domain Controllers OU.

How to find a Global Catalog server?

With DNS Requests (NSLOOKUP)

In an Active Directory environment, all Global Catalogs are anchored in DNS . There is a separate subdomain ‘GC._msdcs ….’ in the namespace of the AD root domain (please remember: the global catalog does not refer to individual domains, but to the entire forest). So if your root domain in the forest is e.g. contoso.com, then you get a list of all GCs with this command:

C:\> nslookup gc._msdcs.contoso.com

Server:  dc.contoso.com
Address:  10.10.67.250

Name:  gc._msdcs.contoso.com
Adresses:  10.10.67.250
10.10.67.251
10.10.67.252
10.10.67.253

The container _msdcs contains the infrastructural DNS records of the Active Directory. This is also where all the SRVservice records for the domain controllers are stored.

With DSQUERY

You can also use the standard command line tool DSQUERY for searching GCs. The search can be limited to certain domains or AD sites. However, you must be authenticated in the regarding forest and DSQUERY must be available on your machine (this is usually the case on Widows servers). As a result, the server objects in the Configuration partition is displayed:

C:\> dsquery server -isgc

“CN=DC,CN=Servers,CN=Site-Sidney,CN=Sites,CN=Configuration,DC=contoso,DC=com”
“CN=DC014,CN=Servers,CN=Site-Auckland,CN=Sites,CN=Configuration,DC=contoso,DC=com”