NTFS File System explained

Intoduction

NTFS is Microsoft’s file system for Windows server and desktop operating systems. This short Windows NTFS tutorial provides information and links breaking down how it works, with details on NTFS vs FAT32, NTFS recovery techniques and management best practices. You’ll also find resources dealing with NTFS compression, permissions and optimization.

NTFS explanations

Windows NTFS, or NT File System, is the standard fyle system of the microsoft operationg systems. Before the Windows NT the fyle system where the Microsoft operating system was installed was FAT (File Alocation Table).

FAT was designed to act as a map for all files stored on a hard disk. FAT went though several incarnations before the creation of the NTFS, from FAT 16 to FA32. Because FAT32 was limited to volumes of 32 GB`s many users these days take the advantage of NTFS for file system management.

NTFS has many advantages over the FAT32 like:

• Access control list (ACL) that increased the folder security and alow administrators to controll who to have access on specific file or folder.
• Informations about a files`s cluster and other data data stored with each cluste, not just a governing table.
• Data security on removable and fixed disks.

In simple terms the difference between FAT and NTFS is that while FAT file system has had a number of modifications made alow it to work with larger hard drives, NTFS file system was originally developed to support large hard disks from the beginning.. Also in adition to the use of large hard drives , NTFS offers more secure directories and files against unauthorized users, has better data protection and doesn`t succumb to errors of fragmentation as easily FAT32.

Another benefit of NTFS over FAT32 involves NTFS permissions. Administrator can user NTFS utility to track permissions and provide ownership of files and folders. This benefit led to NTFS file and folder permissions to quickly become the most common form of authorization since windows 2000. 

Of course, NTFS permissions were not without some issues. For example, what if NTFS permissions were set to control user access to files, but administrators could still potentially grant themselves permissions to certain restricted documents? The classic “Who will watch the watcher” scenario is naturally all about trust, but was sometimes proacively dealt with for NTFS through auditing tools designed to inform you whenever a change was made.

Data Recovery in NTFS

As one would expect, recovery for NTFS works quite differently than FAT32 recovery. For starters, the NTFS file system is designed to perform file recovery on its own, without the need for third-party data recovery utilities or administrative actions. This is made possibe by two technologies: cluster remapping and transaction logging.

Cluster remapping is a technique that prevents data loss by automatically moving data from clusters containing bad sectors on the hard disk to good clusters. The transaction loggingfeature of the NTFS file system is designed to prevent data corruption. Although the mechanics behind transaction logging in NTFS are complicated, the basic idea is that when a write operation occurs, the Windows NTFS file system records the operation to a log file. Once the write operation is logged, NTFS updates the volume cache and then makes a log entry indicating that the transaction is complete. For more information on how cluster remapping and transaction logging work, check out this article on NTFS data recovery.

There are also some free NTFS recovery tools out there. One such tool is FreeUndelete 2.0, which is designed specifically for the recovery of files deleted from NTFS volumes. For example, say you accidentally deleted a file on an external NTFS-formatted hard drive, and you needed to get it back right away. FreeUndelete is a great free tool for fast NTFS data recovery in instances just like that.

What about NTFS recovery of encrypted files? The trick here is that you must have an authorized private key and a file encryption key that was encrypted using the corresponding public key. Without these keys, there is no way to recover NTFS encrypted files. For a detailed rundown of the process, check out this article on recovery of encrypted files on an NTFS partition.

While the NTFS file system was designed to be much less prone to corruption than FAT32, acorrupt boot sector can somtimes occur, requiring the recovery of NTFS data. The boot sector is critical to Windows NTFS, so if it’s corrupt, the entire volume may be inaccessible. To repair a corrupt boot sector in NTFS, all you need to do is locate the backup copy, then use the information it contains to overwrite the primary boot sector. You can then begin the NTFS data recovery process.

Best practices

There are several expert-recommended best practices to be aware of when working with Windows NTFS. One such suggestion involves NTFS cluster sizes. Since larger cluster sizes speed up disk access, it might be tempting to ramp up the cluster size as far as possible (up to 256K) on a big partition with big files. This isn’t always the smartest thing to do, however, as many third-party utilities aren’t designed to recognize NTFS clusters larger than 4K. Many defragmentation programs, for instance, cannot work correctly when confronted with a non-standard cluster size. Therefore, If you plan on using third-party disk tools, creating RAID arrays or mirrored disks, experts advise that you don’t edit the NTFS cluster size by hand.

There are many different ways to optimize NTFS performance. These techniques include having you or an administrator format NTFS legacy filenames or resize the master file table. For the latter, this involves making sure that there is enough space reserved for the master file table at all times. This is important becuase the NTFS master file table is essentially a directory of all of the files and folders found on the hard disk volume (similar to FAT), so it is critical to the volume’s performance that the master file table remains as unfragmented as possible.

Other Window NTFS optimization techniques include disabling the last access date security feature, minimizing the impact of antivirus utilities, and keeping NTFS compression to a minimum. The latter is especially important, because Windows NTFS compression doesn’t compress files by clusters. Instead, it uses compression units of 16 clusters and calculates file space on the basis of the number of compression units needed. This wastes an average of eight clusters of additional space for each file. In a typical user’s account with hundreds or thousands of files, that space adds up, and when it is charged against users’ quotas, they run out of quota space even though the file size on their screen shows that they still have plenty of space left in their quotas.

It’s also recommended that administrators beware of ACLs on NTFS volumes from old Windows installations. This is because NTFS Access Control Lists (ACLs) and Security Descriptors describe who can access what NTFS objects, and to what degree. If a given user or group has access to an object, the ACL for that object will contain a reference to that user or group not by their name, but by their GUID. This means that if you have an object somewhere on an NTFS partition that belongs to a user on a specific machine, those permissions are unique. You can’t create a user with the same name on another machine and expect to have unrestricted access to that object; you have to take ownership of the object first. By following these steps, you can reverse Windows NTFS object ownership from administrators to object’s creator.

Finally, administators should also take action against NTFS disks that fill up too quickly. This can be the result of compromised systems and corrupted disks, as well as other factors, such as master file table expansion and invalid file names.

 

 

 

An overview of implementing AD LDS

AD LDS is implemented in Windows Server 2008 as a server role. To install the server role, use Server Manager to add the role. To install the server role on a Windows Server 2008 computerrunning Server Core, run the start /w ocsetup DirectoryServices-ADAM-ServerCore command. During the role installation, you do not need to make any installation decisions other than choosing to install the role. In order to install AD LDS, your user account must be a member of the local Administrators group.

Configuring Instances and Application Partitions

After installing the AD LDS server role, you use the Active Directory Lightweight Directory Services Setup Wizard to create AD LDS service instances. Multiple instances of AD LDS can run simultaneously on the same computer. Each instance of the AD LDS directory service has a separate directory data store, a unique service name, and a unique service description that is assigned during installation. When you run the wizard, you also have the option of creating an application directory partition.

To create a new AD LDS instance by using the Active Directory Lightweight Directory Services Setup Wizard, complete the following steps:

1. Start the Active Directory Lightweight Directory Services Setup Wizard. You can start the wizard from the Administrative Tools menu or from Server Manager.
2. On the Welcome page, click Next.
3. On the Setup Options page, you have a choice of creating a new instance or creating a replica of an existing instance, as shown in image. Click A Unique Instance and then click Next.

4. On the Instance Name page, provide a name for the AD LDS instance that you are installing. The name that you choose must meet the following requirements:
❑ It must be different from other ADAM instances running on the same computer.
❑ It must be no longer than 44 characters.
❑ It must use characters only from the ranges of a through z, A through Z, or 0 through 9.
❑ The name ntds cannot be used.
5. On the Ports page, specify the communications ports that the AD LDS instance uses to communicate. AD LDS can communicate using both LDAP and Secure Sockets Layer (SSL).

6. On the Application Directory Partition page, you can create an application directory partition during the AD LDS installation, as shown in Figure below. If you do not install an application directory partition now, you must create an application directory partition manually after installation. When you create the application partition, you must provide a fully qualified partition name.

7. On the File Locations page, you can view and change the installation directories for AD LDS data and recovery (log) files. By default, AD LDS data and recovery files are
installed in %ProgramFiles%Microsoft ADAMinstancenamedata, where instancename represents the AD LDS instance name that you specified on the Instance Name page.
8. On the Service Account Selection page, select an account to be used as the service account for AD LDS. The account that you select determines the security context in which the AD LDS instance runs. The Active Directory Lightweight Directory Services Setup Wizard defaults to the Network Service account.

9. On the AD LDS Administrators page, select a user or group to become the default administrator for the AD LDS instance. The user or group that you select will have full administrative control of the AD LDS instance. By default, the Active Directory Lightweight Directory Services Setup Wizard specifies the currently logged-on user. You can change this selection to any local or domain account or group on your network.
10. On the Importing LDIF Files page, you can import schema .ldf files into the AD LDS instance, as shown screenshot.

11. On the Ready To Install page, review your installation selections. After you click Next, the Active Directory Lightweight Directory Services Setup Wizard copies files and sets up AD LDS on your computer.

 

 

AD LDS Management Tools

 

In most cases, after you install an AD LDS instance, you will install the application that will use the instance (in fact, the application may install AD LDS and configure the instance for you). However, you can also manage AD LDS instances by using the administration tools provided with AD LDS.

Using the ADSI Edit Tool

ADSI Edit is a Microsoft Management Console (MMC) snap-in for general administration of AD LDS. It is installed as part of the AD LDS and AD DS server roles. To use ADSI Edit to administer an AD LDS instance, you must first connect to the instance. When you open ADSI
Edit for the first time, it is not connected to any directory. To connect to a directory, on the Action menu, click Connect To. On the Connection Settings screen, you must provide the following information:
■ A name for this connection If you choose one of the well-known naming contexts, this name is filled in for you.
■ A connection point This can be a well-known naming context like the configuration or schema partitions, the rootDSE object, or the Default naming context (which only applies to AD DS domains or application directory partitions). If you want to connect to an application directory partition, you must enter the distinguished name of the application directory partition.
■ The server to which you are connecting If you are using a port other than the standard LDAP ports, you must also provide the port number for the connection.

 

 

Using the Ldp.exe Tool

Ldp.exe is a tool that can be used to administer any LDAP directory service. To use Ldp.exe to administer an AD LDS instance, you must connect and bind to the instance and then display the hierarchy (tree) of a distinguished name of the instance:
1. To connect to an instance using LDP, open a command prompt and type Ldp.exe and then press Enter.
2. On the Connection menu, click Connect. Provide the server name and the port used for the AD LDS instance and choose whether or not to use SSL.
3. After connecting to the instance, you need to provide your credentials by binding to the instance. On the Connection menu, click Bind.
❑ To bind using the credentials that you logged on with, click Bind As Currently Logged-on User.
❑ To bind using a domain user account, click Bind With Credentials; then type the user name, password, and domain name (or the computer name if you are using a local workstation account) of the account that you are using.
❑ To bind using just a user name and password, click Simple Bind and type the user name and password of the account that you are using.
❑ To bind using an advanced method (NTLM, Distributed Password Authentication (DPA), Negotiate, or Digest), click Advanced DIGEST. Then click Advanced, and in the Bind Options dialog box, select the desired method and set other options as needed.

4. After you have been authenticated, on the View menu, click Tree. Type or select the distinguished name for the directory partition that you want to connect to.
5. To view information about the objects in the directory partition, click the object in the left pane. Detailed information about the object is displayed in the right pane, as shown in next figure .

 

6. To edit the object, right-click the object and select one of options for modifying the object or adding child objects.

 

Using the Dsdbutil Tool

Dsdbutil is a directory service management tool that provides much of the same functionality as Ntdsutil does for AD DS. With Dsdbutil, you can:
■ Backup and perform authoritative restores of AD LDS data.
■ Move the AD LDS data files.
■ Change the AD LDS service account and port numbers.
■ List all of the AD LDS instances running on a server.

To use Dsdbutil, start the utility from a command prompt. Then connect to a specific instance by typing Activate Instance instancename. To see all of the commands available in Dsdbutil, type Help. Like Ntdsutil,  Dsdbutil also provides context sensitive help, so typing Help at any
command prompt will display all of the options available in that context.

Configuring Access Control

In AD LDS, each directory object has an access control list (ACLs) that determines which users have access to that object. By default, ACLs are assigned only at the top of each directory partition. All objects in a given directory partition inherit these ACLs. If your application required specific permissions to be assigned at different levels in the directory structure, you can use tools such as Dsacls and Ldp.exe to view and assign permissions. Dsacls is a command-line tool that can be used to view and modify permissions in a directory like AD LDS. Dsacls uses the following syntax.

dsacls object [/a] [/d {user | group}:permissions […]] [/g {user | group}:permissions […]] [/i:{p | s | t}] [/n] [/p:{y | n}] [/r {user | group} […]] [/s [/t]]

Dsacls uses permissions bits in the command to configure permissions on the object. For example, dsacls provides the generic permissions: GR – Generic Read, GE – Generic Execute, GW – Generic Write, and GA – Generic All.

You can also use Ldp.exe to configure permissions on AD LDS objects. To configure permissions using LDP, complete the following steps:
1. Open Ldp.exe and then connect and bind to an AD LDS instance.
2. On the View menu, click Tree View and then select the directory partition that you are connecting to.
3. Right-click the directory partition object for which you want to modify the permissions, click Advanced, and then click Security Descriptor. The Security Descriptor dialog box displays all access control entries (ACEs) and their assigned access rights over the selected directory partition object.

4. Click anywhere in the discretionary access control list (DACL) and then click Add ACE.  Type the distinguished name of the user account and select the appropriate permissions. You can also choose to allow or deny permissions and configure permission inheritance.