Technical posts about IT

Posts in category Troubleshooting

How Domain Controllers are Located Across Trusts

May22
2013 Leave a Comment Written by Sean Metcalf

The ASK PFE Blog has a great article on “How Domain Controllers are Located Across Trusts“.

Hi AskPFEPlat readers. Tom Moser here. A question I get on a pretty frequent basis from my larger, multi-forest enterprise customers is:

“Do I need to add subnets from Forest A to Forest B so that clients find the correct DC across the trust?”

And here’s how I try to answer that question, usually with a lot of words, a little white boarding, and a lot of pointing. I thought, “this needs pictures…” so here you go.

If you’re in a hurry to get back to /r/sysadmin, the short answer is no. If you want to know why, keep reading. Then maybe cross post this for me there.

*** Point of Clarification ***

This post is about the a scenario where the subnets in the two forests do not overlap (i.e., client’s IP address from forest A is not covered by any subnet in forest B). This would typically occur in resource forest scenarios with separate networks. For example: federating via trust with Microsoft online services or a trust between a corporate forest and a perimeter forest. Everything you’re about to read below assumes that the client IP from Forest A is not covered by any subnet in Forest B.

In cases where the two forests have conflicting subnets (for example, 10.1.1.0/24 means site “Detroit” in Forest A, but means site “Siberia” in Forest B), there are additional considerations. We will cover these in a later post.

Read the rest of the article

 

Google+FacebookEmailPrintShare
Posted in Deployment, Tech, Technical Reference - Tagged ,

AD Trivia: Where does the domain SID come from?

May15
2013 Leave a Comment Written by Sean Metcalf

When promoting the first Domain Controller for a new domain, the domain SID is the same as the computer SID of the new DC.

The following AD groups are considered “local” to the Domain Controllers:

  • Administrators
  • Backup Operators
  • Print Operators
  • Server Operators

What’s interesting is that these groups are the local groups from the first DC promoted for the new domain, so the SID matches.

Mark Russinovich states this scenario well in his blog:

As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.

The really interesting scenario is one where Company A owns Company B & Company C and while the IT shop keeps the domains for each domain separated, they build all the DCs from the same image (but don’t sysprep or change the SID meaning the first DC for each domain has the same machine SID and thus the same domain SID). Company A sells off Company B & Company C. Later on Company B & Company C merge and want to set up AD trusts between them. They can’t because the domains in both Company B & Company C have the same SID and a trust can’t reference its own SID!

 

Google+FacebookEmailPrintShare
Posted in Favorite, Microsoft Products, Tech, Technical Reference - Tagged , , ,

Interesting SharePoint Issue

Jul11
2012 Leave a Comment Written by Sean Metcalf

Sometimes I come across an interesting configuration issue – this is one of them.  SharePoint 2010 provides the capability to email documents to a document library. In order to configure SharePoint incoming email, SMTP has to be installed on the server first and incoming email enabled.  If you encounter an error while attempting to enable SharePoint incoming email, check alternate access mapping URLs – mine had the Central Administration website configured with the shortname “portal” instead of the fully qualified domain name of “portal.metcorp.org”.

After enabling and configuring SharePoint for incoming email (including the OU where contact objects are created by SharePoint), it is possible to configure a SharePoint document list with an email alias. If the SharePoint service account doesn’t have appropriate rights to this OU to create contacts (and groups), you will get an error attempting to configure a document library with an email alias.

Additionally, if the contact objects created by SharePoint aren’t configured with the following attribute values, emailed attachments are stripped:

  • InternetEncoding = 1310720
  • MapiRecipient = False

 

Here’s some PowerShell code to automatically set these values on SharePoint managed contacts (you have to configure the OU in the code in which SharePoint creates the contacts):

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Import-Module ActiveDirectory

$SharePointContactsOU = "OU=Contacts,OU=SharePoint,OU=Enterprise,DC=metcorp,DC=org"
Write-Output "Getting a list of contact objects in the SharePoint OU ($SharePointContactsOU) `r "
[array]$SharePointContacts = Get-ADObject -filter { ObjectClass -eq "contact" } -SearchBase $SharePointContactsOU -property DisplayName,targetAddress,internetEncoding,mapirecipient
[int]$SharePointContactsCount = $SharePointContacts.Count

Write-Output "Attempting attribute update of the $SharePointContactsCount contact object(s) in the SharePoint OU ($SharePointContactsOU) `r "
ForEach ($Contact in $SharePointContacts)
    {  ## OPEN ForEach $Contact in $SharePointContacts
        $ContactName = $Contact.name
        $ContactDisplayName = $Contact.DisplayName
        Write-Output "Updating attributes on the contact object: $ContactName (DisplayName: ;$ContactDisplayName) `r "
        TRY { Set-ADObject $Contact -replace @{ "internetEncoding" = "1310720" } } CATCH { Write-Warning "An error occured while attempting to update the attribute internetEncoding with the value of 1310720 " }
        TRY { Set-ADObject $Contact -replace @{ "mAPIRecipient" = $false } } CATCH { Write-Warning "An error occured while attempting to update the attribute mAPIRecipient with the value of false " }
        [array]$ContactObjectInfo = Get-ADObject $Contact -property DisplayName,targetAddress,internetEncoding,mapirecipient
        IF ($ContactObjectInfo) { $ContactObjectInfo ; Write-Output " `r " }
    }  ## CLOSE ForEach $Contact in $SharePointContacts
Google+FacebookEmailPrintShare
Posted in Deployment, Powershell Code, Tech - Tagged , , , ,

Windows 2008 NSPI Connection Changes

Feb19
2012 Leave a Comment Written by Sean Metcalf

Windows 2008 changed the NSPI from unlimited to 50 connections. This can affect a number of applications including Symantec , Blackberry , and others.

The real issue involves 3rd party (non-Microsoft) products (again, like Symantec & Blackberry) .
While Symantec may recommend setting this value to 0xffffffff (~4 billion) effectively rolling back this setting (to be fair, they do state it may not be desirable to set the max limit and provide a formula). I would not recommend setting NSPI to such a high value. Set it to 100 or 150 to see if that resolves the issue first. Then gradually increase the number by about 100.
The real issue is the application needs to be tweaked to handle the connection limit.

From Microsoft KB 949469:
To resolve this issue, check all NSPI connections that processes on the client create for connection leaks. For example, a call to the NspiBind function must have a corresponding call to the NspiUnbind function when an NSPI connection is no longer required. This operation may require that you debug any custom scripts or applications that are using NSPI. If this issue affects external applications, contact the software vendors for updates.

Note The Outlook NSPI MAPI provider that is installed with Microsoft Outlook is only intended for use with Microsoft Outlook. External scripts and applications that rely on the Outlook NSPI MAPI provider are not supported.

References:

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged , , , , , ,

DNSLint: DNS Troubleshooter

Feb12
2012 Leave a Comment Written by Sean Metcalf

One of the best DNS tools a Windows admin can use is DNSLint.
While nslookup is ok for quick DNS lookups, DNSLint is like the swiss army knife of DNS troubleshooting.

DNSLint popular command options:

  • Test domain DNS records:  dnslint /d domain.com
  • Test Active Directory records:  dnslint /ad <DC_IP_ADDRESS> /s <DNS_SERVER>
Note: Add /v for verbose output & /test_tcp to test DNS servers via TCP port 53.
References:

DNSLint Command Options:

DNSLint
Verifies domain name registration and DNS records
usage:
C:\dnslint\dnslint.exe /d domain_name | /ad [LDAP_IP_address] | /ql input_file
[/c [smtp,pop,imap]] [/no_open] [/r report_name]
[/t] [/s DNS_IP_address] [/v] [/y]
Required parameters:
/d used to request domain name tests
– must specify domain name to test
– cannot be used in conjunction with /ad
/ad used to request Active Directory tests
– resolves DNS records used for AD forest replication
– default is to use local system’s LDAP service
– can specify remote LDAP server IP address (optional)
– only valid IP addresses accepted – names not accepted
– typically this is an Active Directory Domain Controller
– must be used with /s option where /s specifies the
IP address of a DNS server that is authoritative for
the _msdcs subdomain in the root domain of the AD forest
– cannot be used in conjunction with /d or /c
/ql used to request DNS query tests from a list
– sends the DNS queries specified in a text input file
– must specify the path and name of the input file
– A, PTR, CNAME, SRV and MX record queries supported
– create a sample input file by running:
dnslint /ql autocreate
– cannot be used in conjunction with /d, /ad, or /c
notes:
– /d /ad /ql cannot be used together
– /c cannot be used together with /ad or /ql
– when using /ad, /s must also be specified
Optional parameters:
/c used to request connectivity tests on e-mail servers
– tests SMTP, POP, and IMAP ports on e-mail servers found
– default is to check all three, can specify one or combination
– use comma seperated list: /c pop,imap,smtp
/no_open used to prevent report from automatically opening
– useful in scripts
/r used to specify the name of the report file created
– .htm extension is automatically added to report names
– report is created in HTML format – default name is dnslint.htm
– default location is the current directory
/t used to request output to a text file
– shares same name as .htm report but with a .txt extension
– created in the same directory as the .htm report file
/test_tcp used to request that TCP port 53 be tested
– by default only UDP port 53 is tested
– this option checks if TCP port 53 is responding to queries
– cannot be used with /ql
/s used by-pass InterNIC whois lookup
– specify tested domain’s authoritative DNS server’s IP address
– does not query InterNIC for registered name servers
– starts checking DNS records using supplied IP address
– only valid IP addresses accepted – names not accepted
– use to check domain names not supported by InterNIC
– when /ad is used, /s must be used to specify a DNS server
that is authoritative for the subdomain called:
_msdcs.<root of the AD forest>
– when /ad is used, /s localhost can be run to determine if
the local system can resolve records used for AD replication
/v used to request verbose output to screen
/y used to overwrite existing report file without being prompted
– useful in scripts
Press Ctrl-c to terminate prematurely
examples:
dnslint /d myserver.com
dnslint /v /y /d reskit.com
dnslint /v /y /r ms_report /d microsoft.com
dnslint /v /y /no_open /s 169.254.1.10 /d msn.com
dnslint /v /y /c /t /d reskit.com
dnslint /d reskit.com /c smtp,pop
dnslint /ad 169.254.10.22 /s 169.254.44.1 /v
dnslint /ad /s localhost /v
dnslint /ql mylist.txt /v
dnslint /ql autocreate

 

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged , , , , , ,

Effective Troubleshooting

Feb05
2012 Leave a Comment Written by Sean Metcalf

There’s a great post on the ASK DS blog site relating to effective troubleshooting.

The steps boil down to:

  1. Understand the System
  2. Check the Plug
  3. Divide and Conquer
  4. Quit Thinking and Look
  5. Change One Thing at a Time
  6. Keep an Audit Trail
  7. Get a Fresh View
  8. If You Didn’t Fix It, It Ain’t Fixed

I would also add to this: Take a Walk. Many times while trying to figure out a problem, I took a 1 to 5 minute walk to get some fresh air and found another take on the problem that frequently leads to a solution.

Check out the blog post for more detail on these steps!

Google+FacebookEmailPrintShare
Posted in Career, Tech - Tagged

Active Directory Replication Site Link Schedules and Time Zones

Jan20
2012 Leave a Comment Written by Sean Metcalf

Here’s an interesting question regarding AD site schedules:

QUESTION:
If there is a DC in Los Angeles & a DC in Washington DC with an AD site schedule of 12pm – 5pm, when does replication actually occur?
Note: There is a 3 hour time difference between LA & DC.

ANSWER:
The Washington DC Domain Controller pulls replication from the Los AngelesDomain Controller from 12pm through 5pm Eastern Time (UTC-5)  which is 5pm – 10pm UTC.

The LA Domain Controller pulls replication from the WashingtonDC Domain Controller from 9am through 2pm Pacific Time (UTC-8) which is 5pm – 10pm UTC.

Remember that a site link only provides the replication path, the InterSite Topology Generator (ISTG) creates the inbound replication connection from connected sites. The replication connection objects are always inbound (one-way) to the DC that creates the connection object. This means there are two one-way replication connection objects representing 2 servers that pull replication from each other (RODCs only perform inbound replication and never replicate out changes).

One caveat to this answer is that the Site Link schedule is stored in UTC time (remember Windows stores time as UTC which is also called GMT) based on the adjusted time at the server where the Site Link schedule is configured. In other words, if a Site Link schedule is configured on a Washington DC server, the schedule will be based on the local time. So, if the Site Link schedule is created on a Washington DC server (as in the example above) for 12:00 – 17:00 (Eastern Time) it is stored as 17:00 – 22:00 (UTC). However, if the Site Link schedule is created on a LA server and AD Sites & Services is pointed to a Washington DC server, the schedule is based on the time of the LA server which would be 12:00 – 17:00 (Pacific Time) and stored as 18:00 – 01:00 (UTC) which means the Washington DC Domain Controller(s) pulls replication from LA at 15:00 – 20:00 (Eastern Time).

Each server determines when it is allowed to replicate based on schedule based on UTC time. If the Site Link is configured for replciation to occur once per hour (the default), and the replication schedule is from 17:00 – 22:00 UTC, replication will likely to occur (start) during the following 5 times:

  • 17:00 -17:15
  • 18:00 -18:15
  • 19:00 -19:15
  • 20:00 -20:15
  • 21:00 -21:15

From TechNet:

Specifically, a replication event is queued at time t + n, where t is the replication interval that is applied across the schedule and n is a pseudo-random number from 1 minute through 15 minutes. For example, if the site link indicates that replication can occur from 02:00 hours through 07:00 hours, and the replication interval is 2 hours (120 minutes), t is 02:00 hours, 04:00 hours, and 06:00 hours. A replication event is queued on the destination domain controller between 02:00 hours and 02:14:59 hours, and another replication event is queued between 04:00 hours and 04:14:59 hours. Assuming that the first replication event that was queued is complete, another replication event is queued between 06:00 hours and 06:14:59 hours. If the synchronization took longer than two hours, the second synchronization would be ignored because an event is already in the queue.

Replication can extend beyond the end of the schedule. A period of replication latency that starts before the end of the schedule runs until completion, even if the period is still running when the schedule no longer allows replication to be available.

References:

 

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged , , , , , , ,

Domain Trusts and the PDC Emulator

Jan19
2012 Leave a Comment Written by Sean Metcalf

Most organizations have a trust relationship in place between 2 (or more) domains and many of those have a firewall situated between trust domains. AD admins have had to deal with this situation for years and have sometimes struggled with firewall admins over what ports need to be configured and which DCs need to talk to other DCs. Most of the time, the PDC emulator in one domain needs to accept communication from the other domain.
Here’s why.

  1. Domain Trust Password Management: The PDC Emulator in the TrustING domain manages the Domain Trust Password and has to communicate with a DC in the TrustED domain.
  2. When granting permissions on a local server resource to a user in a TrustED domain, the server (in the TrustING domain) contacts the PDC Emulator in the TrustED domain to over port UDP 138 to perform resolution of the user name. Prior to Windows 2000, the computer would fall back on the local domain PDC to request name resolution. With Windows 2000 and newer OS, there is no reliance on the local domain PDC.

This means that if there is communication problems between PDCs in different domains (with 2-way trusts), there will be a variety of trust errors.

References:

 

Google+FacebookEmailPrintShare
Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged , , ,

Active Directory Replication Packet Capture

Jan18
2012 Leave a Comment Written by Sean Metcalf

I was interested in what happens behind the scenes when a Domain Controller replicates to another, so I ran a packet capture to see what happens behind the scenes.

My test environment for this packet capture is a single forest, single domain environment with two DCs, both of which running Windows Server 2008 R2. On one DC, I created a new OU and several groups. The following packet data is from the replication from MetcorpOrgDC01.metcorp.org to MetcorpOrgDC02.metcorp.org (the new objects were created on DC01), so Dc02 makes requests of Dc01 and DC01 responds to Dc01.

Here are the main packets from the Active Directory replication traffic flow (minus TCP data):

  1. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.      A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Request: call_id 54 Fragment: Single opnum: 2 ctx_id: 1
    DCERPC: Response: call_id 54 Fragment: Single ctx_id: 1
    DCERPC: Alter_context: call_id: 55 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 55 Fragment: Single accept max_xmit: 5840 max_recv: 5840
  2. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
  3. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Request: call_id 55 Fragment: Single opnum: 2 ctx_id: 1
    DCERPC: Response: call_id 55 Fragment: 1st ctx_id: 1
    DCERPC: Alter_context: call_id: 56 Fragment: Single
    DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 56 Fragment: Single accept max_xmit: 5840 max_recv: 5840
  4. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges response
  5. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 57 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 57 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 57 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 57 Fragment: Single accept max_xmit: 5840 max_recv: 5840
  6. Directory Replication Service: DsReplicaSync
    When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication cycle, where it behaves like a client and makes DSGetNCChanges requests to that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from. This function implements a changes propagation mechanism.
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
  7. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 56 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 56 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 56 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 56 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 56 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 56 Fragment: Single DRSUAPI V4.0
  8. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  9. NTP Time Synchronization
    Although the Windows Time service is not an exact implementation of the Network Time Protocol (NTP), it uses the complex suite of algorithms that is defined in the NTP specifications to ensure that clocks on computers throughout a network are as accurate as possible. Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer.
    NTP: NTP Version 3, Symmetric active
    NTP: NTP Version 3, server (Peer Clock Stratum, Peer Polling Interval, Peer Clock Precision, Root Delay,Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, Receive Timestamp, TransmitTimestamp, Key ID, Message Authentication Code)
  10. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 58 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 58 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 58 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 58 Fragment: Single DRSUAPI V4.0
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
    DCERPC: Alter_context: call_id: 57 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 57 Fragment: Single
    DRSUAPI V4.0
  11. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  12. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 58 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 58 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 58 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 58 Fragment: Single DRSUAPI V4.0
  13. Directory Replication Service: DsReplicaSync
    When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication cycle, where it behaves like a client and makes DSGetNCChanges requests to that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from. This function implements a changes propagation mechanism.
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
  14. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Bind: call_id 59 Fragment: Single, 2 context items, 1st DRSUAPI 4.0
    DCERPC: Bind_ack: Call_id: 59 Fragment: Single accept max_xmit: 5840 max_recv: 5840
    DCERPC: Alter_context: call_id: 59 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 59 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context: call_id: 59 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 59 Fragment: Single DRSUAPI V4.0
  15. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  16. NTP Time Synchronization
    Although the Windows Time service is not an exact implementation of the Network Time Protocol (NTP), it uses the complex suite of algorithms that is defined in the NTP specifications to ensure that clocks on computers throughout a network are as accurate as possible. Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer.
    NTP: NTP Version 3, Symmetric active
    NTP: NTP Version 3, server (Peer Clock Stratum, Peer Polling Interval, Peer Clock Precision, Root Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, Receive Timestamp, Transmit Timestamp, Key ID, Message Authentication Code)
  17. Directory Replication Service: DsReplicaSync
    When a DC receives a DSReplicaSync Request, then for each DC that it replicates from (stored in RepsFrom data structure) it performs a replication cycle, where it behaves like a client and makes DSGetNCChanges requests to that DC. So it gets up-to-date AD objects from each of the DC’s which it replicates from. This function implements a changes propagation mechanism.
    DRSUAPI: DsReplicaSync request
    DRSUAPI: DsReplicaSync response
  18. Microsoft RPC connection (DCERPC)
    DCE/RPC is a specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol.  A DCE/RPC server’s endpoint mapper (EPMAP) will listen for incoming calls. A client will call this endpoint mapper and ask for a specific interface, which will be accessed on a different connection. After that, the client can request calls to the server.
    DCERPC: Alter_context: call_id: 60 Fragment: Single DRSUAPI V4.0
    DCERPC: Alter_context_resp: call_id: 60 Fragment: Single DRSUAPI V4.0
  19. Directory Replication Service: DsGetNCChanges
    The DsReplicaSync function synchronizes a destination naming context (NC) with one of its sources.
    DRSUAPI: DsGetNCChanges request
    DRSUAPI: DsGetNCChanges response
  20. NTP Time Synchronization
    Although the Windows Time service is not an exact implementation of the Network Time Protocol (NTP), it uses the complex suite of algorithms that is defined in the NTP specifications to ensure that clocks on computers throughout a network are as accurate as possible. Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer.
    NTP: NTP Version 3, Symmetric active
    NTP: NTP Version 3, server (Peer Clock Stratum, Peer Polling Interval, Peer Clock Precision, Root Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, Receive Timestamp, Transmit Timestamp, Key ID, Message Authentication Code)

References:

Google+FacebookEmailPrintShare
Posted in Microsoft Products, Packet Capture, Tech, Technical Reference - Tagged , , , , , , , ,

Active Directory Domain Trusts & Trust Password Management

Jan15
2012 1 Comment Written by Sean Metcalf

Recently a customer asked me about Active Directory Domain Trusts and how the passwords were managed. I replied with some educated guesses based on how AD manages a variety of passwords. After stating how I thought it worked (and mentioned that I wasn’t sure), I decided to look it up. I was mostly correct.

Every trust a domain maintains is represented by a Trusted Domain Object (TDO) in the Domain partition’s System container. The TDO contains the following attributes for a domain trust:

  • DNS domain name
  • Domain SID
  • Trust type
  • Trust transitivity
  • Reciprocal domain name

Forest trusts store the following attributes:

  • DNS domain name
  • Domain SID
  • Trust type
  • Trust transitivity
  • Reciprocal domain name
  • Domain tree names
  • User Principal Name (UPN) suffixes
  • Service Principal Name (SPN) suffixes
  • Security ID (SID) namespaces

Since trust information is stored in Active Directory, all domains in the forest know about all of the trusts in place with all forest domains. External NT 4 trusts are not stored as TDOs and therefore are not in Active Directory.

In a one-way trust, there is a TrustED and TrustING domain.
The TrustING domain has the resources that the account in the TrustED domain needs to access. Since a two-way trust is only 2 one-way trusts, there are actually 2 trust passwords involved.

Here’s how trust passwords are managed:

  1. After the trust is created, the password is stored in the associated TDO object.
  2. After 30 days the PDC emulator in the trustING domain changes the password by creating a new one. The trustED DC never attempts to change the password.
  3. The TrustING DC updates the associated TDO OldPassword attribute to the value of the prior password.
  4. The TrustING DC updates the associated TDO NewPassword attribute to the value of the new password.
  5. This way there are always 2 trust passwords associated with the trust, the old password and the new (current) one. This ensures that even if there is an issue with the password change on the TrustED side, the trust remains active since both sides still have a useful password (OldPassword).
  6. The TrustING domain DC connects to a TrustED domain controller via RPC to provide the updated password.
  7. The TrustED DC receives the new password and updates its existing trust password.
  8. Since the trust password is stored in the Domain container in the associated TDO, all the DCs in the domain receive the updated trust password via regular AD replication.
  9. Until the TrustING DC authenticates to a TrustED DC using the new password, the new password is not valid. The old password is used over secure channel until the new password is updated in the TrustED domain and validated.
  10. If authentication fails with the new password, it falls back to the old password and the the password change resumes within 15 minutes.
  11. It is expected that trust passwords are updated among all domain DCs within a day and have a default lifetime of 30 days (same as domain computer accounts). Obviously, trusts can get out of sync if both sides of the trust don’t update and store the new password properly.

Trust Limitations:

  • More than 2400 Trusted Domain Objects (TDOs) incurs noticeable delays specifically related to inter-domain authentication.
  • There is a maximum of 10 trust links Kerberos clients (Windows 2003) can traverse to locate a requested resource in another domain. If the trust path starts approaching 10, it is better to create external trusts to bypass this issue.

Realm Trust:

A realm trust is a trust between a non-Windows Kerberos realm and a Windows 2000/2003/2008 domain which enables cross-platform Kerberos (v5) interoperability.

  • Only supports Kerberos v5 authentication (not NTLM).
  • One-way & nontransitive by default, but can be switched to transitive. configure 2 one-way trusts to enable a two-way trust relationship.

NOTE:
Windows Server 2003 administrative tools sign and encrypt all LDAP traffic by default.

Command Line Tools for managing trusts:

  • NLTest
    “You can use the NLTest command-line tool to perform trust-related network administrative tasks such as testing the trust relationship between a Windows–based computer that is a member of a domain and the domain controller on which its computer account is located. In domains where an external trust is defined, NLTest can be used to test the trust relationship between all domain controllers in the trusting domain and a domain controller in the trusted domain. Nltest can also be used to verify any secured channel.“
  • NetDom
    Netdom is a command-line tool that allows you to create and manage Active Directory trust relationships (except forest trusts) and can help reduce the number of steps needed to create a trust by using Active Directory Domains and Trusts. You can also use the Netdom command line tool to complete batch management of trusts, join computers to domains, verify trusts (including forest trusts) and secured channels, and obtain information about the status of trusts.    Netdom can be targeted at all Active Directory domain controllers and can verify all Active Directory trust types. Verification is accomplished between two domains by enumerating the domain controllers in each domain. If you choose to have Netdom create both sides of the trust at once the trust password is automatically generated.

WMI Classes Associated with Trusts

Class Name Namespace Version Compatibility
Microsoft_TrustProvider root\microsoftactivedirectory Windows 2000 Server and Windows Server 2003
Microsoft_DomainTrustStatus root\microsoftactivedirectory Windows 2000 Server and Windows Server 2003
Microsoft_LocalDomainInfo root\microsoftactivedirectory Windows 2000 Server and Windows Server 2003

Ports Required for Trusts

Task Outbound Ports Inbound Ports From–To
Set up trusts on both sides from the internal forest LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint resolution — portmapper (135 TCP) Net Logon fixed port

  N/A Internal domain domain controllers–External domain domain controllers (all ports)
Trust validation from the internal forest domain controller to the external forest domain controller (outgoing trust only) LDAP (389 UDP)

Microsoft SMB (445 TCP)

Endpoint resolution — portmapper (135 TCP) Net Logon fixed port

  N/A Internal domain domain controllers–External domain domain controllers (all ports)
Use Object picker on the external forest to add objects that are in an internal forest to groups and DACLs  N/A LDAP (389 UDP and TCP)

Windows NT Server 4.0 directory service fixed port

Net Logon fixed port

Kerberos (88 UDP)

Endpoint resolution portmapper (135 TCP)

 External server–Internal domain PDCs (Kerberos)

External domain domain controllers–Internal domain domain controllers (Net Logon)
Set up trust on the external forest from the external forest  N/A LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

 External domain domain controllers–Internal domain domain controllers (all ports)
Use Kerberos authentication (internal forest client to external forest) Kerberos (88 UDP)  N/A Internal client–External domain domain controllers (all ports)
Use NTLM authentication (internal forest client to external forest)  N/A Endpoint resolution – portmapper (135 TCP) Net Logon fixed port External domain domain controllers–Internal domain domain controllers (all ports)
Join a domain from a computer in the internal network to an external domain LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint resolution — portmapper (135 TCP) Net Logon fixed port

Windows NT Server 4.0 directory service fixed port

  N/A Internal client–External domain domain controllers (all ports)

To specify the services that you want to run on a fixed port, you must appropriately configure the registry for that port.

References:

 

 

Google+FacebookEmailPrintShare
Posted in Favorite, Microsoft Products, Tech, Technical Reference - Tagged , , , , , , , ,
« Older Entries
Content Disclaimer: This blog and its contents are provided "AS IS" with no warranties, and they confer no rights. Script samples are provided for informational purposes only and no guarantee is provided as to functionality or suitability. The views shared on this blog do not represent the views of Metcorp Consulting, LLC or its partners. Content Ownership: All content posted here is intellectual work and under the current law, the poster owns the copyright of the article. Terms of Use Copyright © 2011 - 2012