Showing posts with label Active Directory. Show all posts
Showing posts with label Active Directory. Show all posts

Friday, July 15, 2011

Firewall on Servers


Windows Firewall: DNS server

Add UDP port 53 and TCP ports 53, 139, and 445 to the Windows Firewall exceptions list.

Windows Firewall: DHCP server
Add UDP ports 67 and 2535 to the Windows Firewall exceptions list on the DHCP server.
Important:
When you create a Windows Firewall exception for the DHCP protocol on a DHCP server, you must set the scope for the exception to Any computer including those on the Internet. If you leave it set to My network (subnet) only, all inbound DHCP Discover packets from client computers are dropped because the IP address of the packet is 0.0.0.0, which is not recognized by the computer as being part of the local subnet. This causes the DHCP process to fail and clients do not receive IP addresses.
Windows Firewall: File server
Enable the File and Printer Sharing exception in Windows Firewall.
Windows Firewall: Print server
Enable the File and Printer Sharing exception in Windows Firewall.
Windows Firewall: Remote access/VPN server
Turn off Windows Firewall. Stop the Windows Firewall/Internet Connection Sharing (ICS) service.
Windows Firewall: Remote installation server
Add TCP ports 139 and 445 to the Windows Firewall exceptions list.
Add UDP ports 67, 69, and 4011 to the Windows Firewall exceptions list.
Windows Firewall: FTP server
Add the port used for incoming FTP traffic to the Windows Firewall exceptions list. This is usually TCP port 21.
Windows Firewall: SMTP server
Add the port used for incoming SMTP traffic to the Windows Firewall exceptions list. This is usually TCP port 25.
For Secure Sockets Layer (SSL) requests, add TCP port 465 to the Windows Firewall exceptions list.
Windows Firewall: Telnet server
Add TCP port 23 to the Windows Firewall exceptions list.
Windows Firewall: Terminal server
Enable the Remote Desktop exception in Windows Firewall.
If Terminal Server and Terminal Server Licensing are running on separate computers, add TCP port 135 to the Windows Firewall exceptions list.
Windows Firewall: SNMP server
Add UDP port 161 to the Windows Firewall exceptions list.
Windows Firewall: Web server
Add the ports used for incoming HTTP and HTTPS traffic to the Windows Firewall exceptions list. These are usually TCP port 80 and TCP port 443, respectively.


Wednesday, July 6, 2011

Changing the Tombstone Lifetime Attribute in Active Directory

The tombstone lifetime must be substantially longer than the expected replication latency between the domain controllers. The interval between cycles of deleting tombstones must be at least as long as the maximum replication propagation delay across the forest. Because the expiration of a tombstone lifetime is based on the time when an object was deleted logically, rather than on the time when a particular server received that tombstone through replication, an object's tombstone is collected as garbage on all servers at approximately the same time. If the tombstone has not yet replicated to a particular domain controller, that DC never records the deletion. This is the reason why you cannot restore a domain controller from a backup that is older than the tombstone lifetime.

By default, the Active Directory tombstone lifetime is sixty days. This value can be changed if necessary. To change this value, the tombstoneLifetime attribute of the CN=Directory Service object in the configuration partition must be modified. This object is located here:
 cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=
Note: Longer tombstone lifetime decreases the chance that a deleted object remains in the local directory of a disconnected DC beyond the time when the object is permanently deleted from online DCs. The tombstone lifetime is not changed automatically when you upgrade to Windows Server 2003 with SP1, but you can change the tombstone lifetime manually after the upgrade. New forests that are installed with Windows Server 2003 with SP1 have a default tombstone lifetime of 180 days.
You can check your tombstone lifetime attribute by using the following command:
 dsquery * " cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,
 dc=" -scope base -attr tombstonelifetime
There are several ways of modifying this attributes value, the easiest is using ADSIEdit.

Using ADSIEdit

The following explains how to modify this attributes value using ADSI Edit.
Note: ADSIEdit is part of the Windows 2003 Support Tools. To get ADSIEdit you need to install the support tools on your computer/DC. Read my "What are the Windows Server 2003 Support Tools? Where can I get them from?" article for more info on how to obtain the Windows Server 2003 Support Tools (insert link to existing article).
In addition, in order to perform the following steps you'll need to be a member of the Enterprise Admins group.
To view or change attribute values by using ADSIEdit:
  1. On the Start menu, point to Run and then type ADSIEdit.msc and press Enter.
  2. Navigate to:
 cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=
Where "ForestRootDN" is the Distinguished Name of your Active Directory Forest Root domain. For example, if your domain's name is kuku.co.il, then the DN for it would be:
DC=kuku,DC=co,DC=il
  1. Right-click and choose properties.
 
4. In the resultant properties dialog, scroll down to tombstoneLifetime, select this attribute and choose Edit.


5. Configure the Tombstone Lifetime Period, then press Ok.


 6.  Click OK and then close ADSIEdit.
When you view properties on cn=Directory Service,cn=Windows NT, cn=Services,cn=Configuration,dc=, if no value is set it means that the default value is in effect. Any value that you type in the Edit Attribute box replaces the default value when you click Set .
The default value for these two attributes applies if the attribute is not set (the initial state of the system).

Friday, July 1, 2011

Create Users for Testing Purposes


Method 2: By using the DSADD USER command:

dsadd user "cn=Test User,ou=Test OU,dc=india,dc=net" -samid 
testuser -upn testuser@india.net -fn Test -ln User -display
"Test User" -pwd P@ssw0rd -disabled no
 This will create one user called "Test User" with all the necessary information (and as I said earlier, more attributes can be easily configured in the same way).
Lamer Note: Note that you want to use the same syntax as above, you must first create the "Test OU" OU in you AD, and also change the DN of the domain to the name of YOUR domain.
However we would like to create many users for testing purposes. Therefore we can use the FOR command like we did before:
FOR /L %i in (1,1,500) DO dsadd user "cn=Test User%i,ou=Test 
OU,dc=india,dc=net" -samid testuser%i -upn testuser%i@india.net
-fn Test -ln User%i -display "Test User%i" -pwd P@ssw0rd -disabled no
This script will create 500 users called Test User1, Test User2 and so on.

Like with NET USER, the DSADD USER command can be used along with a text or CSV file that contains a list of all the users that you want to build.
Create a text file like this one:
Blue,Kelly,bluek,04-6545645
Ben-Sachar,Ido,bensachari,03-7634545
Fluegel,Jay,fluegelj,03-9875765
Grande,Jon,grandej,02-6674534
Hankin,Alex,hankina,04-8856476
Name the file USERS.TXT and place it in a directory.
Now open a CMD in that directory and run the following command:
for /F "eol=; tokens=1,2,* delims=," %%i in (users.txt) do 
dsadd user "cn=%%j %%i,ou=Test OU,dc=india,dc=net" -samid 
%%k -upn %%k@india.net -fn %%j -ln %%i -display "%%j %%i" 
-pwd P@ssw0rd -disabled yes
This will create user accounts with the names found in the USERS.TXT file.
Imagine the power of such a script!

Create Users for Testing Purposes


Method 1: By using the NET USER command:

FOR /L %i in (1,1,500) DO NET USER MyUser%i /ADD
This will result in creating 500 new users, named MyUser1, MyUser2, etc. You can, of course, customize the FOR command's parameters. See the FOR command help for more options.
You can also set the user's password (in this case - P@ssw0rd) in the same manner:

FOR /L %i in (1,1,500) DO NET USER MyUser%i P@ssw0rd /ADD
You can delete all those users by running the following command:

FOR /L %i in (1,1,500) DO NET USER MyUser%i /DELETE


Note: If run on a stand alone W2K Server, W2K PRO or on an XP machine, this script will create local users. If run on a DC it will create users in the USERS Container in the AD. However, doing so on a domain controller will not create fully AD-compatible users (as you can clearly see if you open one of these users and try to find the User Principal Name - UPN - field).

Note: If you're using a W2K PRO or XP PRO computer that is connected to an Active Directory network and you wish to create local users on that computer - run the command above. However, if you want, from that computer, to create users in the Active Directory database on the DC, use this command instead:

FOR /L %i in (1,1,500) DO NET USER MyUser%i P@ssw0rd /domain /ADD
To create users with pre-configured names (for example - a file with all your company's usernames or a database with usernames) create a text file like this one:

daniel
moshe
yossy
gabi
ran
Name the file USERS.TXT and place it in a directory.
Now open a CMD in that directory and run the following command:

FOR /F %i in (users.txt) DO NET USER %i P@ssw0rd /domain /ADD
This will create user accounts with the names found in the USERS.TXT file, all with the same password - P@ssw0rd. You don't have to use the /domain switch unless you want to.

Change Recovery Console Password

On Windows Server 2003, the setpwd or NET USER trick won't work. Here, if you want to change the Directory Service Restore Mode Administrator password you'll need to use the following method:
1.                  Click, Start, click Run, type
ntdsutil
and then click OK.
  1. At the Ntdsutil command prompt, type
set dsrm password
  1. At the DSRM command prompt, type one of the following lines:
To reset the password on the server on which you are working, type
reset password on server null
The null variable assumes that the DSRM password is being reset on the local computer. Type the new password when you are prompted. Note that no characters appear while you type the password.
or
To reset the password for another server, type
reset password on server
where is the DNS name for the server on which you are resetting the DSRM password. Type the new password when you are prompted. Note that no characters appear while you type the password.
  1. At the DSRM command prompt, type q.
  2. At the Ntdsutil command prompt, type q to exit.
You can now use the Administrator account to log on to Recovery Console or Directory Services Restore Mode using the new password.

Friday, December 17, 2010

Structure of Active Directory

There are two types of structure of Active Directory:
1) Logical Structure of Active Directory:
2) Physical Structure of Active Directory:


1) Logical Structure of Active Directory:
Active Directory provides secure storage of information about objects in its hierarchical logical structure.

The logical structure  of A.D. includes the following components:
a) Object: Object is the most basic components of the logical structure.Everything stored in A.D. is called object.

Friday, December 10, 2010

What is Active Directory?

Active directory is a directory service which store information about all objects such as user, group, computer, and network resources that are created in active directory.
Active directory provide many functions such as:
  1. Centralize control of network resources.
  2. Centralize and decentralize resource management.
  3. Store objects securely in a logical structure.
  4. Optimize network traffic.

***Keep Smiling***

Tuesday, June 1, 2010

Trust

Trusts are the mechanism that ensure that a user who is authenticated in his domain can access resources in my trusted domain.


Trust Type:-
  1. Parent/Child Trust      --  Implicit & transitive
  2. Tree/Root Trust         --  Implicit & transitive
  3. Shortcut Trust            --  Explicit & partially transitive
  4. Transitive Trust          --  automatically extend from one domain to an other domain
  5. Non-Transitive Trust  --  not automatic, you must be set up
  6. Implicit Trust              --  An automatic trust
  7. Explicit Trust              --  Manually create trust
  8. Forest Trust               --  Explicit & partially transitive
  9. External Trust            --   Explicit & non-transitive
  10. Realm Trust               --   Explicit & transitive or non-transitive(user choice)
Trusted Domain:-   Who is accessing the resources.

Trusting Domain:-   Who is providing the resources.


Trust Direction:-

In win 2003 server, there are 3 trust directions:-
  1. One-way incoming
  2. One-way outgoing
  3. Two-way

Trusted Domain Objects:-

Each trust relationship in a domain is represented by an object knows as the Trusted Domain Object(TDO). The TDO stores information about the trust,such as trust type & trust Transitivity. Whenever you creat a trust, a new TDO is created & stored in the system container in the Trust's Domain.

**Keep Smiling...**
    Pradeep Shukla

Monday, May 24, 2010

Seizing FSMO Roles

Seizing FSMO Roles:

   The five FSMO roles are:


Schema master -       Forest-wide and one per forest.

Domain naming master -      Forest-wide and one per forest.

RID master -      Domain-specific and one for each domain.

PDC -      PDC Emulator is domain-specific and one for each domain.

Infrastructure master -     Domain-specific and one for each domain.

 Important:
 Seize the roles only if the original FSMO role owner will not be brought back into the environment.If the RID, Schema, or Domain Naming FSMOs are seized, then the original domain controller must not be activated in the forest again. It is necessary to reinstall Windows if these servers are to be used again.

Before seizing roles user must be member of:

--------------------------------------------------------------------------
FSMO Role                         Administrator must be a member of

--------------------------------------------------------------------------
Schema                                 Schema Admins

Domain Naming                 Enterprise Admins

RID                                         Domain Admins

PDC Emulator                     Domain Admins

Infrastructure                     Domain Admins


--------------------------------------------------------------------------
 
Caution:


Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.

STEPS:
  1.  On any domain controller, go to command prompt.
  2. type Ntdsutil.
  3. type roles.
  4. type connections
  5. type connect to server  servername,  where is the name of the server where you want to transfer roles, and then press ENTER
  6. quit
  7. quit
  8. type seize  role, where is the role you want to seize.  Examples are:
Seize domain naming master

Seize infrastructure master

Seize PDC

Seize RID master

Seize schema master

You will receive a warning window asking if you want to perform the seize. Click on Yes.

9. quit

FINISH.....

****Keep Smiling..****
           Pradeep

Wednesday, May 19, 2010

Global Catalog Server


How many Global Catalog Servers to have on your network?


Where to place those servers? About this things Administrator should have thing at least once :).

You could cause severe performance problems or possibly a single point of failure, If there are jast few Global Catalog Servers. At the same time, having too many Global Catalog Servers can also cause performance problems. In this article, you will see some techniques for determining how many global catalog servers you need.


Why Are Global Catalog Servers So Important? (BTW, about this question you could be asked on every Interview :))


Global Catalog Servers, they are simply domain controllers that have been designated to perform the Global Catalog server role. The first domain controller in the forest is automatically assigned the Global Catalog server roll, because every forest requires at least one Global Catalog server. The Global Catalog server performs a variety of tasks, both for Windows and for Exchange. If a Global Catalog server is not available, then nobody will be able to log into the domain except for the Administrator.

Global Catalog server performs some critical functions at the Active Directory level and in relation to Exchange Server it's also very critical.

In order for clients to be able to send and receive mail, both the Outlook client and the Exchange Server must be able to query a global catalog server. Without access to a Global Catalog server, Outlook clients will not be able to open the Global Address List or resolve the e-mail addresses of message recipients within the forest.

Now let’s talk about placement. Any domain controller that’s running Windows 2000 or Windows Server 2003 can be designated to be a Global Catalog server. I saw networks, where every domain controller act as a Global Catalog server. Equally, this is a bad idea. Global Catalog servers produce quite a bit of traffic applied to the replication process.


Some Network Consultans or System Administrators says, that you should place a Global Catalog Server into any site that contains a server that’s running an application that makes use of port 3268 (Global Catalog lookup port). Exchange Server is such an application, so if you were to follow this rule, then you would want to place a Global Catalog server into any site that contains an Exchange Server.

You can find a Microsoft document that suggests placing a Global Catalog server into each site. I believe that this is the best idea. The fact that clients make use of the global catalog during the logon process. But, Microsoft also says, that a site doesn’t need a Global Catalog server if the site does not contain any servers running Global Catalog dependant applications, such as Exchange or contains fewer than 100 users.

In large organizations with lots of Exchange mailboxes, Global Catalog server could start working VERY hard. Microsoft recommends having one Global Catalog Server for every four mailbox servers.


If you have a single site, single domain network, then it is safe to designate all of your domain controllers to act as Global Catalog servers. Becouse all of the domain controllers contain full copies of the Active Directory you will not get any performance problems by having multiple Global Catalog servers will be minimal.

It is important to make sure that our system uses Global Catalog servers in an optimal manner. Global Catalog servers are so critically important to the Active Directory and to Exchange.



For more information about windows 2003 server & VMWare