How Windows applies Security Settings?

1. How Windows applies Security Settings?

Answer: I didn't find any documents on how and when the system loads security settings during boot or logon process. But as Security Template is imported into a Group Policy Object, the settings you defined in template become part of Group Policy. The final effective security settings for a GPO are written into GptTmpl.inf that under

%systemroot%\sysvol\sysvol\domain name\policies\GPO guid\machine\microsoft\windows\windows nt\secedit

System will compile all effective GPOs' GptTmpl.inf files into secedit.sdb under
%systemroot%\security\database

Please also keep in mind the following points:
- Security settings will be applied everytime its containing GPO is applied
- you can write a template but not to use it; similarily, you can create a GPO but not to link it anywhere
- Security Template itself is just a plain text file and has no effect on the computer. Therefore changing a template does not change any behavior unless you import this template into an EFFECTIVE GPO
- Once you import a Security Template into a GPO, system makes changes in GptTmpl.inf accordingly; If this is an effective GPO, the system will make changes into secedit.sdb then
- When the GPO is applied, the security settings are applied as they are just part of GPO now
- The "Computer Configuration" will be applied each time the computer boots; and the security settings are refreshed every 90 minutes on a workstation or server and every 5 minutes on a domain controller thereafter. The settings are also refreshed every 16 hours, whether or not there are any changes.
- An effective GPO is one that is linked to somewhere, it could be domain, site, OU, or local. And GPOs are applied in the order of local, site, domain, and OU whenever a computer boots into domain. Only Local Group Policy will be applied if it's a standalone server.

2. If templates are compared against security databases after every reboot what files are involved and how does the server know where to look for this information? this may relate to question 4. If this is not the case, how can I ensure that the server will use only a policy I have explicitly set.

Answer: It looks for secedit.sdb under the path mentioned in item 1 when the computer reboots.
If you make manual security settings changes, or import a security template into an effective GPO, the changes will be writen into secedit.sdb during the policy refresh cycle

3. Also in the folder c:/winnt/security/databases there are multiple sdb files. Is the server only looking for secedit.sdb file or will it read all *.sdb files in the database directory?

Answer: Only secedit.sdb. See also Answer 1 and 2.

What is SMB, NT LM, and Samba?

http://samba.anu.edu.au/cifs/docs/what-is-smb.html

Post with the permission of the author Richard Sharpe
==========================================================
On Tue, 14 Jun 2005, John Lan wrote:
> Hi Richard,>> First of all, thank you for a concise yet clear article on SMB at > http://samba.anu.edu.au/cifs/docs/what-is-smb.html>> Can I put it on my website http://strongline.blogspot.com/? Although > it's public accessible, it's mainly for my own use as an online notebook.>> Best regards,> John Lan
Sure, no problems.
Regards-----Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com/

High-watermark vector and Up-To-Dateness vector in depth

1. The up-to-dateness vector contains an entry for each domain controller that holds a full replica of the directory partition.
2. The high-watermark vector contains an entry for each domain controller that holds a full replica of the directory partition.

3. Each DC maintains its own, local only, Local USN, on each partition. In the mean time, each DC has a copy of originating USN table.
4. When an attribute is modified(added/removed ...), the local USN is increased by one and assigned to the attribute, the orginating DSA and originating USN are changed/assigned as well. Within an object, the highest USN of all attributes becomes the object's usnChanged, which is an attribute of an object

Note: The maping tables of attributes and USNs are stored locally on DC, they are not part of AD[After more research, I realized that this statement was wrong. Local USNs are stored in AD as well as a blob operational attribute, but you can't view them from normal LDAP]. However, usnChanged is part of an object. Keep in mind that the attribute "usnChanged" is not replicated therefore on different DCs it has different values.
Unlike Local USN, the originating USN/DSA will travel with the new attribute value when replication happens

5. When requested, source DC sends updates in increasing USN order to the destination DC, the destination DC will keep the USN(local to source dc) of the latest updates it receives from a specific DC/partition. This USN is called the High-Watermark to that particular DC/partition. It's guaranteed that object on source DC/partition that have a usnChanged value lower or equal to the High-Watermark have been replicated to Destination DC.

The above statement has two implication:
1) High-watermark is used to filter irrelevant objects from being considered when replication happens between two DCs
2) All High-Watermark values for different DC/partitions together is call High-Watermark vector. It contains value for only directly replication partners.

6. Up-To-Dateness vector is similar to High-Watermark vector except that it contains the highest originating USNs from all source DCs from which it ever gets updates. The source DC compares the Up-To-Dateness value(from Destination DC) to its local originating USN table to decide what attributes need to be replicated. In other words, is used to filter irrelevant attributes from being replicated