The following steps must be performed in order to initialize a trust relationship between the update server and its clients. Call SetSigningCertificate to install a self-signed certificate. This method has three overloads. Call Save to add this information to the configuration. Add the Certificates snap-in, and set it to manage certificates for the local computer account.
Navigate to the WSU S node in the snap-in, and then find the certificate you added in step 1. Right-click the certificate and select All Tasks , then Export. For security reasons, you should export only the public key, not the private key. Configure your WSUS server to trust this certificate by installing the public key for this certificate in your trusted publisher store. After executing each of these commands you will be prompted to supply a password for the account.
This password should match the password supplied when creating the Cross-Realm trust in the Active Directory Domains and Trusts snap-in as performed previously in step 5. Account mappings are used to map a foreign Kerberos identity in a trusted non-Windows Kerberos realm to a local account identity in the domain.
These account mappings are managed through the Active Directory Users and Computers snap-in. These account mappings will allow the non-Windows Kerberos realm to act as an account domain.
Users with non-Windows Kerberos principals that have mappings to domain accounts, can logon to a workstation that is joined to a trusted domain using the non-Windows Kerberos principal and password from the non-Windows Kerberos realm. If you need to access downlevel Windows NT systems, the domain account that is used for mapping, needs to have a password that is synchronized to the non-Windows Kerberos principal password.
Start the Active Directory Users and Computers snap-in. Figure 9. Advanced Features. Locate the account to which you want to create mappings, and right-click to view Name Mappings. This example uses the account teresa. Click the Kerberos Names mappings tab. Add a principal from the foreign MIT realm.
Figure Kerberos Name Mapping. The following illustration shows the architecture of the transitive cross-realm trust with a child domain. Cross-realm trust to parent domain. In order for child domains or other domains in a forest of Windows Server functional level to make use of a Cross-Realm trust between a non-Windows realm and its parent domain there are some operations that need to be completed.
This is not available in Windows or Windows Server interim functional level forests. Mark the Cross-Realm trust as ForestTransitive. To do this run the following netdom. Confirm the name suffix addition with the following command:. Output should look similar to the following:. Name Type Status Notes. The command completed successfully. The samples are located in the following directory:. See the readme file in the gss-sample directory for more information.
Create the keytab using the following command:. COM —mapuser. Copy sample. Import sample. Start the GSS server. Text similar to the following will be displayed. Authenticate with an account from the non-Windows Realm:. Start the GSS client:. COM Kerberos realm, and the host is krbhost. Received message: "Kerberos interop works great.
NOOP token. COM", lifetime , flags , locally initiated, open. Signature verified. Create a sample2 service account with the following example command:. Set the servicePrincipalName on the service account with the following example command:. An example of the command and the subsequent output from the sample follows. The output of gssserver running on Windows Server looks similar to the following:. Accepted connection using mechanism Kerberos.
Received message : "Kerberos interop works great. The output of gss-client running on the MIT client looks similar to the following:. You can use Klist to verify the tickets issued to the MIT client system. The output will be similar to the following:. Valid starting Expires Service principal. Use the sample account and keytab from the example above.
On the Windows Server system, start gssclient. The output of gss-client running on Windows Server looks similar to the following:. The output of Klist running on Windows Server looks similar to the following:. Cached Tickets: 2. Once the trust relationship has been configured, you can access trust properties through the same property page shown in Figure You can also view the properties of each trust on the incoming or outgoing list, and for those trusts that you created manually, you can change the scope of authentication domain -wide or selective.
For some types of trusts such as realm trusts , where you have to select trust transitivity , you can also change transitivity. As shown in Figure , trust properties can be used to validate a trust relationship after it has been created on both ends. This is also a valuable troubleshooting tool. Last but not least, if the trust relationship. You will be prompted whether this trust should be removed from the external domain as well, in which case you will have to provide an administrative username and password for the external domain.
The built-in group called Incoming Forest Trust Builders allows for granting rights to external root domain administrators to configure trust relationships with your domain, without giving administrative authority in your domain.
As usual with UI-based administration tools in Windows Server , there is a command-line alternative for the Active Directory Domains and Trusts console: the Netdom.
It has the same functionality as the console and more, also allowing you to reset secure channel passwords without having to redo the trust. The following listing shows a portion of the Netdom. All of this is good, but so far, we have still not reviewed what practical implications these trust relationships have for users of the system.
Two main functionalities come to mind: remote resource access, and local authentication console logon in the trusting domain.
0コメント