Tuesday 16 November 2010
Microsoft Secure Desktop
See here http://blogs.msdn.com/b/uac/archive/2006/05/03/589561.aspx for good explanation of how the secure desktop works.
Friday 22 October 2010
Modifying security settings of GPO directly through SYSVOL
Occasionally you may need to remove some of the security settings applied to a GPO directly.
In this case, navigate to the policy folder in SYSVOL.
Then, inside the policy folder, choose Machine - Microsoft - Windows NT - Secedit and open up the GptTmpl.inf file.
So, for example, to remove all settings associated with services, delete the lines from [Service General Setting] to the end of the last service line.
Saving this file and then opening GPMC (ensuring that the GPMC console is pointing at the same DC that you made the edit on), you'll see that all system service settings have been removed.
When is this useful? Well, if you mess around with the service security settings and decide that you no longer want to touch security of the services through the GPO, it is pretty much impossible to reset to the default permissions without actually explicitly setting the default permissions on the service, at which point you're still controlling access permissions within the GPO.
In this case, navigate to the policy folder in SYSVOL.
Then, inside the policy folder, choose Machine - Microsoft - Windows NT - Secedit and open up the GptTmpl.inf file.
So, for example, to remove all settings associated with services, delete the lines from [Service General Setting] to the end of the last service line.
Saving this file and then opening GPMC (ensuring that the GPMC console is pointing at the same DC that you made the edit on), you'll see that all system service settings have been removed.
When is this useful? Well, if you mess around with the service security settings and decide that you no longer want to touch security of the services through the GPO, it is pretty much impossible to reset to the default permissions without actually explicitly setting the default permissions on the service, at which point you're still controlling access permissions within the GPO.
Monday 4 October 2010
Group Policy Preferences - Registry Items
Specifically focusing on the type of Action that can be selected, and the difference between Update and Replace. Microsoft has the following references to this topic. However, to make it clear the following tests several scenarios under a Replace action compared to an Update action:
Scenario: New registry item defined for HKLM\Software\Newkey. DWORD registry item defined here called NewItem1, with a value of 1.
The Newkey folder does not exist to begin with.
Test | Update | Replace |
NewItem1 = 1 defined in GPO. | Registry key and value created in registry | Registry key and value created in registry |
Manually add new items into registry under Newkey. | After GPO refresh they remain. | After GPO refresh they remain. |
Update GPO so that NewItem1 = 2 | Registry updated as well. | Registry updated as well. |
Delete NewItem1 from registry. | GPO puts it back. | GPO puts it back. |
Manually change NewItem1 = 5 in registry. | GPO changes it back to 2. | GPO changes it back to 2. |
Rename NewItem1 to NewItem2 in registry. | GPO creates NewItem1 again, leaving NewItem2 in place. | GPO creates NewItem1 again, leaving NewItem2 in place. |
Rename NewItem1 to NewItem5 in GPO. | New item created in registry so that both NewItem1 and NewItem5 are present. | NewItem1 is renamed to NewItem5 in the registry as well. |
Delete NewItem1 registry item from the GPO. | Remains in registry. | Deleted from registry. |
Thursday 23 September 2010
Group Policy Processing - Refresh intervals
Worth having this information to hand as I always tend to forget the default refresh intervals.
They are:
Standard computers - every 90 minutes with a random offset of 0 to 30 minutes. GPO for computers is also updated whenever a restart is performed.
Domain Controllers - every 5 minutes.
This can then be configured differently using GPO:
They are:
Standard computers - every 90 minutes with a random offset of 0 to 30 minutes. GPO for computers is also updated whenever a restart is performed.
Domain Controllers - every 5 minutes.
This can then be configured differently using GPO:
- Computer Configuration - Administrative Templates - System - Group Policy- Group Policy refresh interval for computers
- Computer Configuration - Administrative Templates - System - Group Policy - Group Policy refresh interval for domain controllers
The refresh interval can be as small as 0 minutes (which means it refreshes every 7 seconds), and as large as 45 days.
Refresh offset times can also be changed for between 0 minutes and 24 hours.
Monday 13 September 2010
Starting an interactive command prompt as the local system
Occasionally you need to run some operations under the credentials of the operating system itself. For instance, if you lock yourself out of a service security descriptor by emptying the DACL, you'll only be able to run sc sdset .... under the SYSTEM account.
Under XP/2003 and before this could be done by running an interactive command prompt under that account via
at
Under Vista/2008 this was perceived as a security hole and so running the command prompt interactively was stopped.
The easiest way to accomplish this now is to use psexec.
Once downloaded you can run:
psexec -i -s -d cmd
You can confirm that the subsequent command prompt is running under the SYSTEM account by typing whoami /user in it.
Under XP/2003 and before this could be done by running an interactive command prompt under that account via
at
Under Vista/2008 this was perceived as a security hole and so running the command prompt interactively was stopped.
The easiest way to accomplish this now is to use psexec.
Once downloaded you can run:
psexec -i -s -d cmd
You can confirm that the subsequent command prompt is running under the SYSTEM account by typing whoami /user in it.
Thursday 9 September 2010
Group Policy Troubleshooting
Windows 7/2008 has a specific event viewer for Group Policy where you can see events focused solely on this.
If you click on the details tab for one of these events, and expand out the System part, you will see an Activity ID. An Activity is defined as something that may spark off several different events. For example, when group policy processing is refreshed, this is a single activity so by filtering on that specific Activity ID you can get all of the events associated with that activity.
Within a single Activity ID you will then see events for each of the GPOs that were processed.
If this is not enough information, you can create log files of all of the GPO processing information.
In the following example I'll set up logging of just group policy preference registry settings:
Once configured all GPO activity relating to the registry part of GPP will be logged.
From this log file it is easy to see details such as when WMI filters apply or get ignored.
For instance, you will see something like this when a WMI filter is passed:
Starting filter [AND FilterWmi].
Adding child elements to RSOP.
Passed filter [FilterWmi].
Filters passed.
If it fails you'll instead see:
Starting filter [AND FilterWmi].
Adding child elements to RSOP.
Failed filter [FilterWmi].
Filters not passed.
If you click on the details tab for one of these events, and expand out the System part, you will see an Activity ID. An Activity is defined as something that may spark off several different events. For example, when group policy processing is refreshed, this is a single activity so by filtering on that specific Activity ID you can get all of the events associated with that activity.
Within a single Activity ID you will then see events for each of the GPOs that were processed.
If this is not enough information, you can create log files of all of the GPO processing information.
In the following example I'll set up logging of just group policy preference registry settings:
- Open up local group policy on a machine (this does not appear to feature in domain GPOs).
- Navigate to Computer Configuration - System - Group Policy - Logging.
- Double click the "Configure Registry preference logging and tracing".
Once configured all GPO activity relating to the registry part of GPP will be logged.
From this log file it is easy to see details such as when WMI filters apply or get ignored.
For instance, you will see something like this when a WMI filter is passed:
Starting filter [AND FilterWmi].
Adding child elements to RSOP.
Passed filter [FilterWmi].
Filters passed.
If it fails you'll instead see:
Starting filter [AND FilterWmi].
Adding child elements to RSOP.
Failed filter [FilterWmi].
Filters not passed.
Friday 21 May 2010
DC Locator Process Refresher
Since I always forget the intricacies of this, here it is:
A client that knows its site will request a DC using a DNS query with the following format:
_ldap._tcp..sites.dc._msdcs.
DCs in this site list will be ordered in random order provided by DNS round robin.
If a client does not know its site, you'll get a DNS query with the following format:
_ldap._tcp.dc._msdcs.
When a client joins the domain using the GUI it does not know its site so you can find that on rebooting it contacts a different DC that doesn't have the domain information for the client.
After a client contacts a DC this information is cached. If this DC is not in the optimal site the cache is flushed after 15 mins and it then tries to find a DC in the same site.
The DC Locator process has been improved with Vista and 2008 so that it has a concept of next closest site. This is not enabled by default and must be done through GPO.
After authentication, the authenticating DC also helps the client find a suitable supplier of \\domain\SYSVOL or \\domain\NETLOGON shares.
It does this by generating 2 lists.
The first is a list of DCs that can offer this share in the client's site (randomly ordered). The second is a list of DCs outside the client site that can offer this share (randomly ordered).
For this reason, the DC being used for authentication need not be the DC being used for SYSVOL information. There is a PreferLogonDC registry entry that can be added to DCs to ensure that the authenticating DC is returned at the top of the list.
A client that knows its site will request a DC using a DNS query with the following format:
_ldap._tcp.
DCs in this site list will be ordered in random order provided by DNS round robin.
If a client does not know its site, you'll get a DNS query with the following format:
_ldap._tcp.dc._msdcs.
When a client joins the domain using the GUI it does not know its site so you can find that on rebooting it contacts a different DC that doesn't have the domain information for the client.
After a client contacts a DC this information is cached. If this DC is not in the optimal site the cache is flushed after 15 mins and it then tries to find a DC in the same site.
The DC Locator process has been improved with Vista and 2008 so that it has a concept of next closest site. This is not enabled by default and must be done through GPO.
After authentication, the authenticating DC also helps the client find a suitable supplier of \\domain\SYSVOL or \\domain\NETLOGON shares.
It does this by generating 2 lists.
The first is a list of DCs that can offer this share in the client's site (randomly ordered). The second is a list of DCs outside the client site that can offer this share (randomly ordered).
For this reason, the DC being used for authentication need not be the DC being used for SYSVOL information. There is a PreferLogonDC registry entry that can be added to DCs to ensure that the authenticating DC is returned at the top of the list.
Thursday 18 March 2010
WINS forwarding through DNS
This is a potentially very useful feature of DNS as it allows you to remove WINS server settings from individual member servers, and allow them to query WINS instead through DNS.
If you click on a DNS zone in the console, you'll see a WINS tab.
There you can enable the option to "Use WINS forward lookup" and then specify the WINS server to use.
What this does is creates a new record of type WINS lookup in the DNS zone.
DNS will always try and answer the query from its local DNS zones but if not can strip down the FQDN to just the hostname and then pass that request to a WINS server.
If WINS can answer the query it will pass the name and IP address to DNS, which then replies as if it came from it's own DNS database.
This also has the advantage of allowing Unix clients to indirectly read WINS databases.
If you click on a DNS zone in the console, you'll see a WINS tab.
There you can enable the option to "Use WINS forward lookup" and then specify the WINS server to use.
What this does is creates a new record of type WINS lookup in the DNS zone.
DNS will always try and answer the query from its local DNS zones but if not can strip down the FQDN to just the hostname and then pass that request to a WINS server.
If WINS can answer the query it will pass the name and IP address to DNS, which then replies as if it came from it's own DNS database.
This also has the advantage of allowing Unix clients to indirectly read WINS databases.
Wednesday 17 March 2010
About domain trusts
Checking for Active Trusts
Each domain trust is stored as a Trusted Domain object in the System container in the domain partition. Regardless of what some documentation states, trusts with NT4 domains still create TDOs.
By querying the whenChanged attribute on the TDO you can determine if the trusts is still active as all trusts involve creating a secure channel to the trusted domain, so the password needs to be reset every 30 days.
Remember that the whenChanged attribute is not replicated so can be different on each DC.
Also beware that the whenChanged attribute is not the same as the creation date of the computer object as the date can be no older than the computer object itself. My golden rule is to ignore any whenChanged dates when they're the same as the whenCreated date of the DC's computer account itself.
Trust Types
nltest /server:nameofDC /domain_trusts
This shows all of the trusts, direction of trust, what sort of trust. Also shows the trust type which is basically what sort of domain it's with.
Can be NT4, NT5, MIT or DCE.
NT4 - this is only NT4 domains.
NT5 - Windows 2000 or higher (not confirmed for W2K8). Functional level of domain is not a factor - it's just the OS.
MIT - realm trust
DCE - have not found an example of this yet.
Verifying Trusts are Working
nltest /SC_VERIFY:trusteddomainname
This, and the netdom command
netdom verify nameofDC /domain:trusteddomainname
can only show details of the secure channel when you're on the trusting domain (so will show a DC on the trusted domain).
There is no way of seeing the secure channel from the trusted domain (presuming it's one-way) as there is no secure channel - the secure channel is only set up from the trusting domain to the trusted domain.
Which DC does a trusting DC set up a secure channel with?
It depends on how it resolves the name of the trusted domain.
It might be using a secondary zone, lmhosts file etc. Quite often this will be using the same as domain name A records. It will then choose at random so to stop this you need to manipulate which DCs it sees as answering to the name of the domain...
Each domain trust is stored as a Trusted Domain object in the System container in the domain partition. Regardless of what some documentation states, trusts with NT4 domains still create TDOs.
By querying the whenChanged attribute on the TDO you can determine if the trusts is still active as all trusts involve creating a secure channel to the trusted domain, so the password needs to be reset every 30 days.
Remember that the whenChanged attribute is not replicated so can be different on each DC.
Also beware that the whenChanged attribute is not the same as the creation date of the computer object as the date can be no older than the computer object itself. My golden rule is to ignore any whenChanged dates when they're the same as the whenCreated date of the DC's computer account itself.
Trust Types
nltest /server:nameofDC /domain_trusts
This shows all of the trusts, direction of trust, what sort of trust. Also shows the trust type which is basically what sort of domain it's with.
Can be NT4, NT5, MIT or DCE.
NT4 - this is only NT4 domains.
NT5 - Windows 2000 or higher (not confirmed for W2K8). Functional level of domain is not a factor - it's just the OS.
MIT - realm trust
DCE - have not found an example of this yet.
Verifying Trusts are Working
nltest /SC_VERIFY:trusteddomainname
This, and the netdom command
netdom verify nameofDC /domain:trusteddomainname
can only show details of the secure channel when you're on the trusting domain (so will show a DC on the trusted domain).
There is no way of seeing the secure channel from the trusted domain (presuming it's one-way) as there is no secure channel - the secure channel is only set up from the trusting domain to the trusted domain.
Which DC does a trusting DC set up a secure channel with?
It depends on how it resolves the name of the trusted domain.
It might be using a secondary zone, lmhosts file etc. Quite often this will be using the same as domain name A records. It will then choose at random so to stop this you need to manipulate which DCs it sees as answering to the name of the domain...
Friday 12 March 2010
DNS Scavenging Revealed
I thought I'd write up how scavenging works in DNS in conjunction with DHCP. There are places that describe the process well, but not everywhere, and nowhere that I've seen has it quite right in terms of timings.
DNS has 2 intervals relating to aging: the no refresh interval and the refresh interval:
No refresh interval - during this time, no refreshes may be made to the timestamp of a DNS record (more about refreshes in a moment), but updates are ok. This is done to prevent unnecessary frequent replication of DNS record changes.
Refresh interval - during this time, the timestamp of the record may be refreshed, at which point the no refresh interval kicks in again.
After the refresh interval has passed, if there has been no refresh (or update) of that record then it is available to be scavenged.
How to set up scavenging:
On the properties of the DNS zone, click on "Aging". Set whatever no refresh and refresh intervals you want. Ensure that you also tick the box to "scavenge stale resource records".
You then also need to tell the server to actually scavenge periodically. I am in favour of a single DC doing the scavenging.
In the properties of the DNS server, on the Advanced tab, check the box to "enable automatic scavenging of stale records", and set the scavenging period. Don't make this too frequent as scavenging hits the server.
Note that if you right click on the DNS server, there is a "set aging/scavenging for all zones..." option. This will, if you wish, allow you to set consistent scavenging options across all hosted zones. I don't use it personally.
That's the easy bit and what you can find on any website.
DNS record Refresh vs Update
A refresh is defined as when the record tries to update its timestamp but its IP address hasn't changed.
An update is when the IP address changes. This kind of operation can always occur as the no refresh interval does not impact on it.
So, let's see the processes in action:
Firstly, DNS refreshes being prevented by the no refresh interval:
The scenario here is that we have a DHCP server, with DHCP lease times set to 10 mins.
This means that DHCP half-life (T1) will occur every 5 mins.
Scavenging is enabled and scheduled every hour, with no refresh interval set to 1 hour, and refresh interval set to 2 hours:
DNS has 2 intervals relating to aging: the no refresh interval and the refresh interval:
No refresh interval - during this time, no refreshes may be made to the timestamp of a DNS record (more about refreshes in a moment), but updates are ok. This is done to prevent unnecessary frequent replication of DNS record changes.
Refresh interval - during this time, the timestamp of the record may be refreshed, at which point the no refresh interval kicks in again.
After the refresh interval has passed, if there has been no refresh (or update) of that record then it is available to be scavenged.
How to set up scavenging:
On the properties of the DNS zone, click on "Aging". Set whatever no refresh and refresh intervals you want. Ensure that you also tick the box to "scavenge stale resource records".
You then also need to tell the server to actually scavenge periodically. I am in favour of a single DC doing the scavenging.
In the properties of the DNS server, on the Advanced tab, check the box to "enable automatic scavenging of stale records", and set the scavenging period. Don't make this too frequent as scavenging hits the server.
Note that if you right click on the DNS server, there is a "set aging/scavenging for all zones..." option. This will, if you wish, allow you to set consistent scavenging options across all hosted zones. I don't use it personally.
That's the easy bit and what you can find on any website.
DNS record Refresh vs Update
A refresh is defined as when the record tries to update its timestamp but its IP address hasn't changed.
An update is when the IP address changes. This kind of operation can always occur as the no refresh interval does not impact on it.
So, let's see the processes in action:
Firstly, DNS refreshes being prevented by the no refresh interval:
The scenario here is that we have a DHCP server, with DHCP lease times set to 10 mins.
This means that DHCP half-life (T1) will occur every 5 mins.
Scavenging is enabled and scheduled every hour, with no refresh interval set to 1 hour, and refresh interval set to 2 hours:
- Scavenging is occurring at 25 past each hour.
- Client powers on at 09:44.
- The timestamp for the record is set to 09:00:00 because all timestamps are rounded down to the nearest hour.
- At 09:49, it attempts to refresh its timestamp in DNS. It is not allowed to do so due to it being in the no refresh interval.
- This goes on every 5 minutes. At 10:04, it tries again. Now, logic dictates that it should be able to refresh its timestamp this time because the no refresh interval is only 1 hour. However (and this is what I've never seen written anywhere else), it can't. This is because, all DNS registrations that occur from 09:00 to 09:59 will have a timestamp of 09:00:00. Therefore, counting only commences at 10:00, so the no refresh interval is officially from 10:00 - 11:00 (and any time before 10:00). Therefore the record timestamp will be refreshed on the first attempt after 11:00 and will be set to 11:00:00.
Now, let's see scavenging in action in the same scenario:
- Scavenging still occurs at 25 past the hour.
- Client is powered on at 13:38. DNS timestamp is set to 13:00:00.
- It tries to refresh its timestamp every 5 mins but is unable to.
- At 14:16 it is powered down.
- At 15:00, its DNS record enters the refresh interval. However, the client is powered down so does not refresh it.
- At 17:00 (2 hour refresh interval), the refresh interval expires and the record becomes eligible for scavenging.
- At 17:25, scavenging runs and the record is deleted.
Matching DHCP and DNS scavenging periods correctly is vital.
Here's an example where they aren't matched. DCs re-register their records every 24 hours by default, or whenever Netlogon is restarted. All clients automatically attempt to refresh their DNS records every 24 hours too.
In this scenario, we have the same scavenging settings as above, but this time, DHCP lease times are set to 4 days.
- Scavenging occurs at 25 past the hour again.
- Client powers on at 08:12 and receives an IP address from DHCP. DNS timestamp is set to 08:00:00. Since the lease time is 4 days, the client will not attempt to refresh its record for 2 days if left up and running.
- Therefore, by the end of the refresh interval at 12:00, the client has not refreshed its record and consequently at 12:25 the record is scavenged, despite the client being up and running and in use all that time.
Therefore, take care with over-zealous scavenging. Know your DHCP lease times!
What are the best settings?
I've heard talk that with a default DHCP lease time of 7 days, no refresh of 3 days and 4 days refresh intervals are good (the idea being that T1 is 3.5 days in, when the refresh interval is in place - again be careful its not the other way round with a no refresh of 4 days as T1 will always fail, though T2 at 87.5% of the way through the lease should succeed).
However, I'm not convinced. If the person goes on holiday for a week, the record will be scavenged - is that good? It might be depending on your point of view. However, by leaving it there it's not necessarily a bad thing. If the client is turned off for a few days and the lease expires, then as soon as it comes back on line and picks up a new IP address, the record is immediately updated anyway so it will always show the latest IP address.
Using DNSCMD to see record timestamps:
I don't like the DNS console much. It's slow to update so I can never trust the information it is giving me is up to date. DNSCMD often will show me that a timestamp is updated well before the console ever does.
If you want to see the timestamps for records in the console, you need to turn on advanced features. If you want to see them using DNSCMD, it's:
dnscmd servername /EnumRecords DNSZoneName @ /Type A
This will show you all A RRs, with timestamps.
Thursday 11 March 2010
DNS Zone info in AD
Server 2003 introduced DomainDnsZones and ForestDnsZones application partitions. These moved DNS data out of the domain partition where it was replicated to the GC to its own partition.
In ADSIEdit you can see where each of the partitions stores DNS zone information (2 domain forest example):
Domain partition - cn=MicrosoftDNS,cn=System,dc=childdomain,dc=example,dc=com
DomainDnsZones partition (child domain) - cn=MicrosoftDNS,dc=DomainDnsZones,dc=childdomain,dc=example,dc=com
DomainDnsZones partition (root domain) - cn=MicrosoftDNS,dc=DomainDnsZones,dc=example,dc=com
ForestDnsZones partition - cn=MicrosoftDNS,dc=ForestDnsZones,dc=example,dc=com
If you try to change the replication scope from one to the other, and receive a message like:
"the name limit for the local computer network adapter card was exceeded"
then this likely to be because the zone already exists in the other location.
e.g. you try and move the replication scope of a DNS zone to DomainDnsZones and receive the message above.
Open up adsiedit and navigate to the relevant location in DomainDnsZones. You will likely already see a copy of the partition you are trying to move there.
Delete it, along with any ...in progress... zones you see there as these are the failed attempts to create the zone.
You will immediately be able to change the replication scope.
How did this get created?
Well, in my case it was creating a Server 2003 forest. This automatically installs DNS to the new partitions. However, I wanted to move them back, as well as move _msdcs.forestname to a sub domain of the forest root to represent how a Windows 2000 forest would look. Therefore, when I came to "upgrade" it to a Server 2003 forest-style DNS configuration again, the partition had already existed from when it was first installed.
_msdcs.forestname
Under Server 2003, this is in its own zone, replicating forest wide.
In Windows 2000, it's a sub-domain of the forest root domain. Which was always a pain as you had to ensure the child DCs also had a copy of the forest root DNS data, often using a secondary zone.
It can be upgraded using the instructions in kb817470.
To downgrade it, as I did here, I had to dfo the following:
The newly created _msdcs zone was deleted followed by the deletion of the automatically created delegation (under the forest name DNS zone), then create a new _msdcs subdomain under the forest name DNS zone and restart the netlogon service on every Domain Controller in the forest in order to force related DC RR registration.
Finally, you may speed the ForestDNSzone NC replication by running repadmin /syncall or /replicate /force commands.
In ADSIEdit you can see where each of the partitions stores DNS zone information (2 domain forest example):
Domain partition - cn=MicrosoftDNS,cn=System,dc=childdomain,dc=example,dc=com
DomainDnsZones partition (child domain) - cn=MicrosoftDNS,dc=DomainDnsZones,dc=childdomain,dc=example,dc=com
DomainDnsZones partition (root domain) - cn=MicrosoftDNS,dc=DomainDnsZones,dc=example,dc=com
ForestDnsZones partition - cn=MicrosoftDNS,dc=ForestDnsZones,dc=example,dc=com
If you try to change the replication scope from one to the other, and receive a message like:
"the name limit for the local computer network adapter card was exceeded"
then this likely to be because the zone already exists in the other location.
e.g. you try and move the replication scope of a DNS zone to DomainDnsZones and receive the message above.
Open up adsiedit and navigate to the relevant location in DomainDnsZones. You will likely already see a copy of the partition you are trying to move there.
Delete it, along with any ...in progress... zones you see there as these are the failed attempts to create the zone.
You will immediately be able to change the replication scope.
How did this get created?
Well, in my case it was creating a Server 2003 forest. This automatically installs DNS to the new partitions. However, I wanted to move them back, as well as move _msdcs.forestname to a sub domain of the forest root to represent how a Windows 2000 forest would look. Therefore, when I came to "upgrade" it to a Server 2003 forest-style DNS configuration again, the partition had already existed from when it was first installed.
_msdcs.forestname
Under Server 2003, this is in its own zone, replicating forest wide.
In Windows 2000, it's a sub-domain of the forest root domain. Which was always a pain as you had to ensure the child DCs also had a copy of the forest root DNS data, often using a secondary zone.
It can be upgraded using the instructions in kb817470.
To downgrade it, as I did here, I had to dfo the following:
The newly created _msdcs zone was deleted followed by the deletion of the automatically created delegation (under the forest name DNS zone), then create a new _msdcs subdomain under the forest name DNS zone and restart the netlogon service on every Domain Controller in the forest in order to force related DC RR registration.
Finally, you may speed the ForestDNSzone NC replication by running repadmin /syncall or /replicate /force commands.
Monday 22 February 2010
Legacy group membership
Once you update the forest to 2003FFL, linked-value replication (LVR) comes into play.
However, this doesn't affect existing group membership entries.
This can be seen through repadmin:
repadmin /showobjmeta DC_Name Dn_of_group
Distinguished Name =============================
ABSENT member 2010-02-19 18:02:53 US\Server1
205479704 205479704 2
CN=user1,OU=Accounts,DC=test,DC=com
PRESENT member 2010-02-22 10:21:05 UK\Server2
208940639 143787850 1
CN=user2,OU=Accounts,DC=test,DC=com
Key
ABSENT - LVR enabled member. This is similar to a tombstoned object - it records a membership that has been removed. This will be garbage collected after the tombstone lifetime has expired.
PRESENT - LVR enabled member.
LEGACY - legacy membership. LVR will not take affect for this member.
These can apply to members and also to "managed by" properties.
LVR enabled basically means that there is additional metadata associated with the membership, stored in msDS-ReplValueMetaData attribute for the group.
If you compare an entry for this attribute before and after a membership is LVR-enabled, you see something like this:
LEGACY member:
member
CN=User1,OU=Accounts,DC=test,DC=com
0
1601-01-01T00:00:00Z
2003-04-11T20:55:09Z
0
1601-01-01T00:00:00Z
00000000-0000-0000-0000-000000000000
0
0
"
Updated PRESENT member:
member
CN=User1,OU=Accounts,DC=test,DC=com
0
1601-01-01T00:00:00Z
2003-04-11T20:55:09Z
2
2010-02-17T18:56:26Z
ebc213fa-1e61-423d-92ca-d938777a2348
7694183
203002792
CN=NTDS Settings,CN=Server1,CN=Servers,CN=UK,CN=Sites,CN=Configuration,DC=test,DC=com
Updating Legacy Memberships
In order to update all memberships and managed-by's to be LVR-enabled, you need to remove that membership and re-add it. This updates the metadata.
I'll try and paste some Powershell to do this later on as a response to this post.
However, this doesn't affect existing group membership entries.
This can be seen through repadmin:
repadmin /showobjmeta DC_Name Dn_of_group
Distinguished Name =============================
ABSENT member 2010-02-19 18:02:53 US\Server1
205479704 205479704 2
CN=user1,OU=Accounts,DC=test,DC=com
PRESENT member 2010-02-22 10:21:05 UK\Server2
208940639 143787850 1
CN=user2,OU=Accounts,DC=test,DC=com
Key
ABSENT - LVR enabled member. This is similar to a tombstoned object - it records a membership that has been removed. This will be garbage collected after the tombstone lifetime has expired.
PRESENT - LVR enabled member.
LEGACY - legacy membership. LVR will not take affect for this member.
These can apply to members and also to "managed by" properties.
LVR enabled basically means that there is additional metadata associated with the membership, stored in msDS-ReplValueMetaData attribute for the group.
If you compare an entry for this attribute before and after a membership is LVR-enabled, you see something like this:
LEGACY member:
"
Updated PRESENT member:
Updating Legacy Memberships
In order to update all memberships and managed-by's to be LVR-enabled, you need to remove that membership and re-add it. This updates the metadata.
I'll try and paste some Powershell to do this later on as a response to this post.
Thursday 4 February 2010
Old password still valid for an hour
Not sure why I haven't blogged this one before.
With Windows Server 2003 Sp1, MS decided to modify NTLM authentication behaviour (this also affects LDAP authentication) so that a user can use their old password for an hour to access the network after it has changed.
This is to allow things like service accounts to still be able to login while the new password propagates.
However, I've never been convinced that the case is there (why does kerberos not need it?).
To disable this feature, you need to modify HKLM\System\CurrentControlSet\Control\LSA\OldPasswordAllowedPeriod. This is a DWORD value.
Setting it to 0 means that you disable the use of old passwords.
If this value is not in the registry the default of 60 minutes is used.
See kb906305 for further details.
With Windows Server 2003 Sp1, MS decided to modify NTLM authentication behaviour (this also affects LDAP authentication) so that a user can use their old password for an hour to access the network after it has changed.
This is to allow things like service accounts to still be able to login while the new password propagates.
However, I've never been convinced that the case is there (why does kerberos not need it?).
To disable this feature, you need to modify HKLM\System\CurrentControlSet\Control\LSA\OldPasswordAllowedPeriod. This is a DWORD value.
Setting it to 0 means that you disable the use of old passwords.
If this value is not in the registry the default of 60 minutes is used.
See kb906305 for further details.
Wednesday 3 February 2010
Using Winbind in Linux to authenticate to AD
Linux has Pluggable Authentication Modules (PAM) to provide a common set of authentication of APIs.
Also has Name Server Switch (NSS) APIs for looking up user information.
This resides on each linux machine.
AD authentication method 1
Have PAM and NSS communicate directly with AD using LDAP. However, LDAP authentication passes in clear text (so would need to use LDAPS). Also need to specify DC.
AD authentication method 2
Get PAM to use Kerberos and NSS to do group membership lookup via LDAP. More secure but still has problem where have to specify DC. Also doesn't manage passwords well.
AD authentication method 3
Use Samba.
Samba has a Winbind daemon that interprets PAM and NSS calls and interprets them into AD calls, using either Kerberos, LDAP or RPC, depending upon which is appropriate.
Winbind can also replicate the DC locator mechanism to find the best DC using SRV records.
Winbind parameters
Winbind domain: Netbios name of AD domain.
Security model: ADS.
Winbind ADS realm: DNS name of domain.
Winbind domain controllers: name of DC or * to get Winbind to use its DC locator mechanism.
ID mapping
NIS is used in Linux often to ensure that a Linux UID is unique on machines.
Can therefore have a mechanism to do a 1:1 mapping of AD users and groups to Linux UIDs. This is a big admin overhead.
Easier method is to get Winbind to extract the RID from the SID when the user logs in and use the RID as the UID.
This has zero admin overhead but won't work in a multi domain environment in case the RID is repeated.
Implementing mapping
To implement mapping, edit etc/samba/smb.conf
AD mapping: add "idmap backend = ad"
RID mapping: add "idmap backend = rid"
Also has Name Server Switch (NSS) APIs for looking up user information.
This resides on each linux machine.
AD authentication method 1
Have PAM and NSS communicate directly with AD using LDAP. However, LDAP authentication passes in clear text (so would need to use LDAPS). Also need to specify DC.
AD authentication method 2
Get PAM to use Kerberos and NSS to do group membership lookup via LDAP. More secure but still has problem where have to specify DC. Also doesn't manage passwords well.
AD authentication method 3
Use Samba.
Samba has a Winbind daemon that interprets PAM and NSS calls and interprets them into AD calls, using either Kerberos, LDAP or RPC, depending upon which is appropriate.
Winbind can also replicate the DC locator mechanism to find the best DC using SRV records.
Winbind parameters
Winbind domain: Netbios name of AD domain.
Security model: ADS.
Winbind ADS realm: DNS name of domain.
Winbind domain controllers: name of DC or * to get Winbind to use its DC locator mechanism.
ID mapping
NIS is used in Linux often to ensure that a Linux UID is unique on machines.
Can therefore have a mechanism to do a 1:1 mapping of AD users and groups to Linux UIDs. This is a big admin overhead.
Easier method is to get Winbind to extract the RID from the SID when the user logs in and use the RID as the UID.
This has zero admin overhead but won't work in a multi domain environment in case the RID is repeated.
Implementing mapping
To implement mapping, edit etc/samba/smb.conf
AD mapping: add "idmap backend = ad"
RID mapping: add "idmap backend = rid"
Subscribe to:
Posts (Atom)