Samba Interdomain Trust with Windows Server 2008 R2

Harald Strack

1 Scenario

We have a samba 3.3.12 domain called CENTRAL connected to our IDM core via LDAP. In our departments we run different versions of Windows domain controllers. Some are Samba based, some Windows 2000, 2003 and 2008.

In this document I will try to describe the necessary steps and tweaks to configure an interdomain trust between the Samba domain CENTRAL and a local domain in an office called OFFICE running a Windows 2008 R2 domain controller. We want to enable the users of the domain CENTRAL (trusted domain) to log into the domain OFFICE (trusting domain) using their CENTRAL domain accounts (e.g. CENTRAL\jsmith).

1.1 CENTRAL Domain Controller (Samba)

In our example the IPs of the domain controllers in the CENTRAL domain are

111.111.111.111
111.111.111.112

and their NetBIOS names are either CENTRALDC and CENTRALDC2.

1.1.1 Create a trust account in LDAP

smbpasswd -a -i OFFICE

The resulting LDAP object should look like this:

dn: uid=OFFICE$,ou=SambaComputers,ou=People,dc=example,dc=com
sambaAcctFlags: [I          ]
sambaPwdLastSet: 1271007506
sambaNTPassword: 0C12345E9A7D7E14B143A9B294764363
sambaPwdMustChange: 2147483647
sambaPwdCanChange: 1271007506
sambaSID: S-1-5-21-1234570140-5432175976-1641233425-101018
objectClass: posixAccount
objectClass: top
objectClass: sambaSamAccount
uid: WI$
cn: NT DOMAIN
uidNumber: 50009
gidNumber: 19999
homeDirectory: /tmp
userPassword: {crypt}*

1.1.2 Roaming Profiles

We use a special setup for Roaming Profiles: when users of the CENTRAL domain log into a workstation of the OFFICE domain, they get a roaming profile hosted from the domain controller of the OFFICE domain.

In the smb.conf of the CENTRAL domain controllers we configure

logon path = \\PROFSERV\profiles\%U

The OFFICE domain controllers are in a different subnet and use WINS to resolve hosts. With the appropriate static wins entries (see below), all our offices are able to use locally hosted Roaming Profiles in conjunction with a central user database.

1.2 OFFICE Domain Controller (W2008R2)

In our example the IP of this domain controller is

222.222.222.222

and its NetBIOS name is LOCALDC.

1.2.1 Static WINS entries

In our scenario, the CENTRAL and the OFFICE domain are in different subnets (indeed they are in different cities). For a interdomain trust we have to configure some static WINS entries that point to the CENTRAL domain controller(s) on the W2008R2 domain controller.

We may also add a PROFSERV entry that points to the W2008R2 server itself (the host with the profiles share). The PROFSERV entry enables us to save Roaming Profiles of CENTRAL users on the OFFICE domain controller (optional).

Importing the static entries from a lmhosts file

The appropriate way to get these entries into the WINS server is to import a lmhosts file like the following:

111.111.111.111     "CENTRALDC      \0x1c"  #PRE
111.111.111.111     "CENTRAL        \0x1c"  #PRE
111.111.111.111     "CENTRAL        \0x1b"  #PRE
111.111.111.112     "CENTRAL        \0x1c"  #PRE
111.111.111.111     "CENTRALDC2     \0x1c"  #PRE
222.222.222.222      PROFSERV     #PRE  #DOM:OFFICE
222.222.222.222      LOCALDC     #PRE  #DOM:OFFICE

Caution: the NetBIOS names must be 16 bytes (chars) long, the first 15 bytes are the name (eventually padded with spaces) the last byte is the network service identifier.

  • The 1c id defines two CENTRAL domain controllers.
  • The 1b id points to the Master Browser that will be used to establish the trust (PDC).

On Windows 2008 R2 the WINS functionality has not changed since 2003. The main entry point of the documentation is here.

  • install and manage WINS
  • open the WINS administration tool, click right on Active Registrations in the tree view on the left side and import the lmhosts file
Configure WINS name resolution

We have to configure the W2008R3 server in the advanced TCP/IP networking options as WINS server, thus pointing to itself (here: 222.222.222.222).

1.3 Workstations

1.3.1 Configure WINS

We have to configure the WINS server for the workstations in the advanced TCP/IP networking. As WINS server we use the IP 222.222.222.222.

1.3.2 Disable Roaming Profiles (optional)

If we do not use the PROFSERV entry, we should disable Roaming Profiles.

By default the workstations will try to load a Roaming Profile for each user. We can't disable this on CENTRAL side since it would affect all connected (trusted) domains. Thus, we have to disable it on client side (workstations) before cloning, as described here:

Start/Run/gpedit.msc

Local Computer Policy/Computer Configuration/Administrative Templates/System/User 
Profiles/Only Allow Local User Profiles.


If you enable both the "Prevent Roaming Profile changes from propagating to the server" 
setting and the "Only allow local user profiles" setting, roaming profiles are disabled.

1.3.3 Routing

  • Apply the same routing table as on the server to prevent errors like Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden.
route -p add ...

1.3.4 IPv6

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents 
0xffffffff 

2 Trust Relationship

2.1 Verification of the previous steps

  • is the CENTRAL domain resolvable from
    1. the Domain Controller
    2. the Workstations

We can verify this with nblookup.exe as described here. The following example queries the WINS server with the IP 222.222.222.222 for the domain controllers that are registered in the domain CENTRAL:

nblookup /s 222.222.222.222 /x 1C CENTRAL
nblookup /s 222.222.222.222 /x 1B CENTRAL

To verify the WINS entries from a CENTRAL domain controller, type:

nmblookup  -U 222.222.222.222 -R 'CENTRAL#1c'
nmblookup  -U 222.222.222.222 -R 'CENTRAL#1b'
  • has the trust account been created successfully in LDAP and do we know the password?
  • Ping test from the local domain controller OFFICE to the central domain controller CENTRAL
ping 111.111.111.111
ping 111.111.111.112
  • smbclient test from the CENTRAL domain controller to the OFFICE domain controller (smb traffic test, check for proxies)
smbclient -L 222.222.222.222
Anonymous login successful
Domain=[OFFICE] OS=[Windows Server 2008 R2 Enterprise 7600] Server=[Windows Server 2008 R2 Enterprise 6.1]

        Sharename       Type      Comment
        ---------       ----      -------
Error returning browse list: NT_STATUS_ACCESS_DENIED
.
.
.
  • There should be at least one workstation of the desired version and service pack in the local domain (OFFICE)

3 Establish a Trust Relationship

In Windows 2008 interdomain trusts are called external trusts and are described here.

We need to configure a One-Way, Outgoing, External Trust for One Side of the Trust on the W2008 Server. Follow the instructions there.

  • On the Trust Name page configure CENTRAL for the external domain.
  • On the Direction of Trust page, click One-way: outgoing. If you do not have this choice look at Troubleshooting

4 Authorization

CENTRAL domain users from the trusted domain can be made members in local groups on MS Windows domain member machines and controllers, but only in local (domain) groups.

To create a local group, select local when adding the group in the Active Directory Users and Groups window.

Then double-click on the group and add users as you desire.

5 Troubleshooting

5.1 Crypto settings

When setting up a Windows 2008 AD Domain the following splash screen appeared

Windows Server 2008 and "Windows Server 2008 R2" domain controllers have a new more secure 
default for the security setting named "Allow cryptography algorithms compatible with Windows 
NT 4.0." This setting prevents Microsoft Windows and non-Microsoft SMB "clients" from using 
weaker NT 4.0 style cryptography algorithms when establishing security channel sessions 
against Windows Server 2008 or "Windows Server 2008 R2" domain controllers. As a result of 
this new default, operations or applications that require a security channel serviced by 
Windows Server 2008 or "Windows Server 2008 R2" domain controllers might fail.


Platforms impacted by this change include Windows NT 4.0, as well as non-Microsoft SMB 
"clients" and network-attached storage (NAS) devices that do not support stronger cryptography 
algorithms. Some operations on clients running versions of Windows earlier than Windows Vista 
with Service Pack 1 are also impacted, including domain join operations performed by the 
Active Directory Migration Tool or Windows Deployment Services.


For more information about this setting, see Knowledge Base article 942564 
(http://go.microsoft.com/fwlink/?LinkId=104751).
  • Further information to this topic is here

However, these settings do not appear to affect the establishment of a trust.

5.2 WINS

When you establish a trust and the dialog straight after entering the remote domain name (CENTRAL) offers you the choice between Realm Trust and a Trust with a Windows Domain, your server could not resolve the remote domain correctly.

Solution: double check your wins entries with nmblookup. Check for the 1b and 1c entries.

5.3 Access to CENTRAL Domain users

When you try to grant any permissions to users from the CENTRAL domain, while you are logged in as a user from the OFFICE domain (e.g. OFFICE\Administrator) you will not find any user.

Background

Whenever a users wants to access the CENTRAL domain, even when he only wants to search users for granting permissions, he has to authenticate first. It is important to understand that the user has to authenticate, not the machine. Now, when you logged in as a user from another domain (e.g. OFFICE\Administrator) you cannot authenticate in the CENTRAL domain with your actual credentials (desktop single sign-on). However, Windows 2008 R2 tries to authenticate at the CENTRAL domain controller several times with the credentials of the OFFICE domain.

Samba Log of a CENTRAL domain controller:

[2010/03/22 12:07:51,  2] lib/access.c:check_access(406)
  Allowed connection from  (222.222.222.222)
[2010/03/22 12:07:51,  2] lib/smbldap.c:smbldap_open_connection(890)
  smbldap_open_connection: connection opened
[2010/03/22 12:07:51,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [Administrator] -> [Administrator] FAILED with error NT_STATUS_NO_SUCH_USER
[2010/03/22 12:07:51,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [Administrator] -> [Administrator] FAILED with error NT_STATUS_NO_SUCH_USER
[2010/03/22 12:07:51,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [Administrator] -> [Administrator] FAILED with error NT_STATUS_NO_SUCH_USER
[2010/03/22 12:07:51,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [Administrator] -> [Administrator] FAILED with error NT_STATUS_NO_SUCH_USER
[2010/03/22 12:07:51,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [Administrator] -> [Administrator] FAILED with error NT_STATUS_NO_SUCH_USER

In earlier versions of Windows appeared a prompt for credentials where the user could enter its credentials in the other domain (CENTRAL).

Solution 1:

Log on to the W2008R2 domain controller as user from the CENTRAL domain. Unfortunately, this is not possible since users from other domains cannot log on to a local domain controller.

"You cannot log on because the logon method you are using is not allowed on this computer. Please see you network administrator for more details."

It may possible to disable this policy as described here.

Solution 2:

Before you start assigning rights to users from the CENTRAL Domain, connect to a share on one of the CENTRAL Domain Controllers (e.g. \\CENTRALDC\netlogon) using your CENTRAL account. Then, Windows 2008R2 will use these credentials to search users in the CENTRAL domain and assigning rights will work. However, depending on the size of your environment, you may not able to get a list of all users, since the LDAP search of the data takes too long and you will see only a small subset of available the users and groups.

5.4 Resolving SIDs

Scenario: you assigned some rights to CENTRAL users on a specific folder. After you log out and log in again, check the permissions on the folder. You may only see the SIDs of these users not their logins.

Background:

On the W2008R2 server of OFFICE I got the following messages in the samba log:

[2010/03/24 09:48:10,  2] lib/access.c:check_access(406)
  Allowed connection from  (222.222.222.222)
[2010/03/24 09:48:10,  2] smbd/sesssetup.c:setup_new_vc_session(1368)
  setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources.
[2010/03/24 09:48:10,  2] smbd/sesssetup.c:setup_new_vc_session(1368)
  setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources.
[2010/03/24 09:48:10,  2] lib/smbldap.c:smbldap_open_connection(890)
  smbldap_open_connection: connection opened
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 60001
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 60001
[2010/03/24 09:48:10,  2] lib/access.c:check_access(406)
  Allowed connection from  (222.222.222.222)
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 60001
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 60001
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 60001
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 60001
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_sam_from_ldap(571)
  init_sam_from_ldap: Entry found for user: OFFICE$
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 19999
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 19999
[2010/03/24 09:48:10,  2] libsmb/credentials.c:netlogon_creds_server_check(223)
  netlogon_creds_server_check: credentials check failed.
[2010/03/24 09:48:10,  0] rpc_server/srv_netlog_nt.c:_netr_ServerAuthenticate2(555)
  _netr_ServerAuthenticate2: netlogon_creds_server_check failed. Rejecting auth request from client LOCALDC machine account OFFICE$
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_sam_from_ldap(571)
  init_sam_from_ldap: Entry found for user: OFFICE$
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 19999
[2010/03/24 09:48:10,  2] passdb/pdb_ldap.c:init_group_from_ldap(2366)
  init_group_from_ldap: Entry found for group: 19999
[2010/03/24 09:48:10,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [LOCALDC$] -> [LOCALDC$] FAILED with error NT_STATUS_NO_SUCH_USER

Explanation:

  • W2008R2 opens an anonymous connection
  • It resolves the nobody / anonymous user several times (60001)
  • It resolves the OFFICE Interdomain Trust Account and the Trust Account group (19999)
  • It successfully authenticates with its Domain name (OFFICE), but shows an error message.
  • It tries to authenticates with its workstation name (LOCALDC) without success.
Solution:

After very detailed analysis of the GPOs / registry of the W2008R2 server I found the essential registry entry:

Network security: Allow Local System to use computer identity for NTLM

This policy setting allows Local System services that use Negotiate to use the computer
 identity when reverting to NTLM authentication.

If you enable this policy setting, services running as Local System that use Negotiate will 
use the computer identity. This might cause some authentication requests between Windows 
operating systems to fail and log an error.

If you do not configure this policy setting, services running as Local System that use 
Negotiate when reverting to NTLM authentication will authenticate anonymously. This was the 
behavior in previous versions of Windows.

This policy is supported on at least Windows 7 or Windows Server 2008 R2.

When this policy is enabled and the machine wants to lookup SIDs, it tries to authenticate with its machine name but we have no machine account for a trusted domain controller in the CENTRAL domain!

Thus, we have to disable this property:

  • Edit the Group Policy object (GPO) that is linked to the domain controller organizational unit.
  • In Group Policy Object Editor, locate the following node:

Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options

  • Open the following policy setting:

Network security: Allow Local System to use computer identity for NTLM

  • Change this policy setting to Disabled.

Further thoughts:

  • This policy seems to be relevant to Windows 7 workstations. We should disable it on such workstations, too!
  • Creating a machine account in the CENTRAL domain for the OFFICE domain controller may also resolve the issue. But how do we enter the machine account's password on the OFFICE domain controller?

5.5 List CENTRAL Domain users

When you try to list all CENTRAL domain users and groups you may get only a small subset. In the samba logs you can't see any errors, but in the LDAP log:

Solution:

We have to set

        ldap timeout = 60
        ldap connection timeout = 2

in smb.conf of the CENTRAL domain controller. In earlier versions of samba there was only the option ldap timeout that had the meaning of the actual ldap connection timeout and you may set ldap timeout to a small value on all CENTRAL domain controllers.

Man page of samba 3.0.24

     ldap timeout (G)
        When Samba connects to an ldap server that  servermay  be
        down or unreachable. To prevent Samba from hanging whilst
        waiting for the connection this  parameter  specifies  in
        seconds  how  long  Samba  should wait before failing the
        connect. The default is to only wait fifteen seconds  for
        the ldap server to respond to the connect request.

        Default:  ldap timeout = 15

Man page of samba 3.3.12

ldap connection timeout (G)

           This parameter tells the LDAP library calls which timeout in seconds they should honor during initial
           connection establishments to LDAP servers. It is very useful in failover scenarios in particular. If one
           or more LDAP servers are not reachable at all, we do not have to wait until TCP timeouts are over. This
           feature must be supported by your LDAP library.

           This parameter is different from ldap timeout which affects operations on LDAP servers using an existing
           connection and not establishing an initial connection.

           Default: ldap connection timeout = 2

ldap timeout (G)

           This parameter defines the number of seconds that Samba should use as timeout for LDAP operations.

           Default: ldap timeout = 15

Further Thoughts:

  • Extensive use of the advance search form might result in a denial of service of the LDAP servers
  • If you configure an additional AD trust from your local domain (OFFICE) to another AD domain, this domain will not be able to access CENTRAL domain accounts, because of the nature of NT4-Trust relationships:

In a NT4-style MS security domain, all trusts are nontransitive. This means that if there are three domains (let's call them red, white, and blue), where red and white have a trust relationship, and white and blue have a trust relationship, then it holds that there is no implied trust between the red and blue domains. Relationships are explicit and not transitive.

New to MS Windows 2000 ADS security contexts is the fact that trust relationships are two-way by default. Also, all inter-ADS domain trusts are transitive. In the case of the red, white, and blue domains, with Windows 2000 and ADS, the red and blue domains can trust each other. This is an inherent feature of ADS domains. Samba-3 implements MS Windows NT4-style interdomain trusts and interoperates with MS Windows 200x ADS security domains in similar manner to MS Windows NT4-style domains.

The behaviour of mixed NT4 / AD trusts has not been investigated further.

6 Tests

This section describes some tests that I performed after the trust worked basically.

6.1 Login

Does the login work correctly?

  • Log into one Machine (roaming profiles disabled with a local policy on the workstation).

Success on the domain controller. The profile is always empty (clean desktop) after logging in.

  • Log into one Machine (roaming profiles enabled, PROFSERV tweak).

Success on the domain controller. The profile is always the same logging in on different machines.

  • The user's home should be mounted as drive Z:. If you do not need it, make sure to unmount it with a logon skript

Success. The home directory is mounted.

6.2 Failover

When a CENTRAL domain controller is down for any reason, will the OFFICE domain controller re-establish a secure channel to another CENTRAL domain controller?

Domain Controller / Domain member servers

  • Assign permissions to a folder

Success. Only tried with users (not with groups)

  • Add CENTRAL users to local groups

Success.

  • Shut down Samba services on the active CENTRAL domain controller (Figure out the IP / name of the active CENTRAL domain controller with netstat on the workstation and on the OFFICE domain controller)

No Success. The trust channel has not been established to another CENTRAL domain controller. It is not possible to assign any permissions anymore.

  • Login and Logout again (the domain controller keeps shut down)

No Success. The trust channel has not been established to another CENTRAL domain controller. But it is possible to login.

  • Start the CENTRAL domain controller again. And login / add permissions.

Success. The trust channel has been reestablished immediately

This behaviour is not the same as when using samba as the OFFICE domain controller. Samba always does a failover to another host with a 1c flag.

Workstations

Not yet tested.

  • Login to a workstation
  • Figure out the IP / name of the active CENTRAL domain controller with netstat on the workstation and on the OFFICE domain controller
  • Logout again
  • Shut down Samba services on the active CENTRAL domain controller

It is not possible to assign any permissions anymore. The

  • Login and Logout again (the domain controller keeps shut down)
  • Start the CENTRAL domain controller again. And login / add permissions.
 
samba_trust_w2008r2_harald_strack.txt · Last modified: 2012/03/24 03:10 (external edit)
Recent changes RSS feed Creative Commons License Driven by DokuWiki Made on Mac