Remotely manage non-domain joined server........

I'm just trying to lab this, I've got my Win2012 domain joined server, I have a Win2012 workgroup server which I've added to server manager and I followed the instructions (link below) but I'm getting a kerberos authentication error in server manager on the domain joined VM ?

Add Servers to Server Manager
I can't seem to figure this out and it's bugging me !

Find more posts tagged with

Comments

joemc3

Read this on authentication! I don't have the answer but i thought this might help.
Figure 1:
Let's take a closer look at this exchange process and its component parts.
[h=4]AS Exchange[/h]When initially logging on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the AS portion of a KDC within their domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network. The following is a discussion of the TGT retrieval process.
[h=4]Example AS Administration[/h]The AS request identifies the client to the KDC in plain text. If preauthentication is enabled, a time stamp will be encrypted using the user's password hash as an encryption key. If the KDC reads a valid time when using the user's password hash (stored in the Active Directory) to decrypt the time stamp, the KDC knows that request isn't a replay of a previous request. The preauthentication feature may be disabled for specific users in order to support some applications that don't support the security feature. Access the user account from the Active Directory users and the computers will snap-in and select the account tab. From the account options: slide window, check mark the "Do not require Kerberos" preauthentication option (Figure 2).

Figure 2: Disable Kerberos Preauthentication
If the KDC approves the client's request for a TGT, the reply (referred to as the AS reply) will include two sections: a TGT encrypted with a key that only the KDC (TGS) can decrypt and a session key encrypted with the user's password hash to handle future communications with the KDC. Because the client system cannot read the TGT contents, it must blindly present the ticket to the TGS for service tickets. The TGT includes time to live parameters, authorization data, a session key to use when communicating with the client and the client's name.
[h=4]TGS Exchange[/h]The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.
The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange coming next.
[h=4]Client/Server Exchange[/h]Once the client user has the client/server service ticket, he can establish the session with the server service. The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.
[h=4]Client/Server Exchange Detail[/h]The client blindly passes the server portion of the service ticket to the server in the client/server request to establish a client/server session. If mutual authentication is enabled, the target server returns a time stamp encrypted using the service ticket session key. If the time stamp decrypts correctly, not only has the client authenticated himself to the server, but the server also has authenticated itself to the client. The target server never has to directly communicate with the KDC. This reduces downtime and pressure on the KDC.
Top of page

[h=3]Further Clarification of the Log-in Process[/h]A TGT and a service ticket are needed to access services on remote computers, but they are also required to successfully log on to a local system. When the log-on window appears, password encryption using a one-way hash algorithm occurs immediately and negotiations commence with the KDC for a valid TGT and service ticket. The process is the same as accessing a remote service. An access token is created for the user containing all security groups to which they belong. This access token is attached to the user's log-on session and is subsequently inherited by any process or application the user starts.
[h=4]Referral Tickets[/h]The AS and TGS functions are separate within the KDC. This permits the user to use the TGT obtained from an AS in his domain to obtain service tickets from a TGS in other domains. This is accomplished through referral tickets.
Once a trust has been established between two domains, referral tickets can be granted to clients requesting authorization for services in other domains. When there is a trust established between the two domains, an interdomain key based on the trust password becomes available for authenticating KDC functions. This can best be explained by example of a user/client seeking services in another domain. As illustrated in Figure 3, a user client in Entcert1.com requests authority for a server in Entcert2.com. He utilizes referral tickets. The numbers in Figure 3 correspond to the following numbered explanations:

The client contacts its domain KDC TGS using a TGT. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the KDC in the foreign domain.
The client contacts the KDC of the foreign domain with the referral ticket. This ticket is encrypted with the interdomain key. Given that the decryption works, the TGS service for the foreign domain returns a service ticket for the server service in Entcert2.com.
The client performs the client/server exchange with the server and begins the user session with the service.

Figure 3: Domain Referrals

When more domains are involved, the referral process extends and involves the transitive properties between Windows 2000 domains. Maintaining individual two-way trusts between all domains creates a complex administrative nightmare. The use of Kerberos transitive domains cuts down on interdomain administration. This can best be explained by example of a user/client seeking services in another domain. As illustrated in Figure 11-4, Entcert1.com has a trust relationship with Entcert2.com. Entcert2.com has a trust relationship with Entcert3.com. There is no trust between Entcert1.com and Entcert3.com. A client from Entcert1.com accessing a service on a server in Entcert3.com would obtain a service ticket through the following steps (the numbers appearing in Figure 4 correspond to the following numbered explanations):

Use the TGS service in Entcert1.com to obtain a referral ticket for a KDC in Entcert2.com.
Use the referral ticket with the TGS service on the KDC in Entcert2.com and obtain a referral for Entcert3.com.
Use the second referral ticket with the TGS service on the KDC for Entcert3.com and obtain a service ticket for the server in Entcert3.com.
Use the Client/Server Exchange to open a session with the service in Entcert3.com.

Figure 4: Transitive Domain Trusts

[h=4]Delegation with Forwarding and Proxy[/h]Some server services require access to a second server, such as a back-end database. In order to establish a session with the second server, the primary server must be authenticated on behalf of the client's user account and authority level. This is common in a three-tier client/server model. This activity is commonly accomplished with proxy or forwarding authentication.
Top of page

[h=3]Postscript[/h]The authentication process implemented by Kerberos is highly effective, but a few hundred words cannot do the subject justice. That is why I recommend that this article be used as a primer and that you seek more in-depth technical white papers, books or consulting services prior to actual implementation. Once you understand Kerberos and how it can serve both a pure Windows 2000 and mixed operating environment then your investment should pay high dividends.

pjd007

joemc3 wrote: »

Read this on authentication! I don't have the answer but i thought this might help.
Figure 1:
Let's take a closer look at this exchange process and its component parts.
AS Exchange

When initially logging on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the AS portion of a KDC within their domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network. The following is a discussion of the TGT retrieval process.
Example AS Administration

The AS request identifies the client to the KDC in plain text. If preauthentication is enabled, a time stamp will be encrypted using the user's password hash as an encryption key. If the KDC reads a valid time when using the user's password hash (stored in the Active Directory) to decrypt the time stamp, the KDC knows that request isn't a replay of a previous request. The preauthentication feature may be disabled for specific users in order to support some applications that don't support the security feature. Access the user account from the Active Directory users and the computers will snap-in and select the account tab. From the account options: slide window, check mark the "Do not require Kerberos" preauthentication option (Figure 2).

Figure 2: Disable Kerberos Preauthentication
If the KDC approves the client's request for a TGT, the reply (referred to as the AS reply) will include two sections: a TGT encrypted with a key that only the KDC (TGS) can decrypt and a session key encrypted with the user's password hash to handle future communications with the KDC. Because the client system cannot read the TGT contents, it must blindly present the ticket to the TGS for service tickets. The TGT includes time to live parameters, authorization data, a session key to use when communicating with the client and the client's name.
TGS Exchange

The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.
The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange coming next.
Client/Server Exchange

Once the client user has the client/server service ticket, he can establish the session with the server service. The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.
Client/Server Exchange Detail

The client blindly passes the server portion of the service ticket to the server in the client/server request to establish a client/server session. If mutual authentication is enabled, the target server returns a time stamp encrypted using the service ticket session key. If the time stamp decrypts correctly, not only has the client authenticated himself to the server, but the server also has authenticated itself to the client. The target server never has to directly communicate with the KDC. This reduces downtime and pressure on the KDC.
Top of page

Further Clarification of the Log-in Process

A TGT and a service ticket are needed to access services on remote computers, but they are also required to successfully log on to a local system. When the log-on window appears, password encryption using a one-way hash algorithm occurs immediately and negotiations commence with the KDC for a valid TGT and service ticket. The process is the same as accessing a remote service. An access token is created for the user containing all security groups to which they belong. This access token is attached to the user's log-on session and is subsequently inherited by any process or application the user starts.
Referral Tickets

The AS and TGS functions are separate within the KDC. This permits the user to use the TGT obtained from an AS in his domain to obtain service tickets from a TGS in other domains. This is accomplished through referral tickets.
Once a trust has been established between two domains, referral tickets can be granted to clients requesting authorization for services in other domains. When there is a trust established between the two domains, an interdomain key based on the trust password becomes available for authenticating KDC functions. This can best be explained by example of a user/client seeking services in another domain. As illustrated in Figure 3, a user client in Entcert1.com requests authority for a server in Entcert2.com. He utilizes referral tickets. The numbers in Figure 3 correspond to the following numbered explanations:
The client contacts its domain KDC TGS using a TGT. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the KDC in the foreign domain.

The client contacts the KDC of the foreign domain with the referral ticket. This ticket is encrypted with the interdomain key. Given that the decryption works, the TGS service for the foreign domain returns a service ticket for the server service in Entcert2.com.

The client performs the client/server exchange with the server and begins the user session with the service.

Figure 3: Domain Referrals

When more domains are involved, the referral process extends and involves the transitive properties between Windows 2000 domains. Maintaining individual two-way trusts between all domains creates a complex administrative nightmare. The use of Kerberos transitive domains cuts down on interdomain administration. This can best be explained by example of a user/client seeking services in another domain. As illustrated in Figure 11-4, Entcert1.com has a trust relationship with Entcert2.com. Entcert2.com has a trust relationship with Entcert3.com. There is no trust between Entcert1.com and Entcert3.com. A client from Entcert1.com accessing a service on a server in Entcert3.com would obtain a service ticket through the following steps (the numbers appearing in Figure 4 correspond to the following numbered explanations):
Use the TGS service in Entcert1.com to obtain a referral ticket for a KDC in Entcert2.com.

Use the referral ticket with the TGS service on the KDC in Entcert2.com and obtain a referral for Entcert3.com.

Use the second referral ticket with the TGS service on the KDC for Entcert3.com and obtain a service ticket for the server in Entcert3.com.

Use the Client/Server Exchange to open a session with the service in Entcert3.com.

Figure 4: Transitive Domain Trusts

Delegation with Forwarding and Proxy

Some server services require access to a second server, such as a back-end database. In order to establish a session with the second server, the primary server must be authenticated on behalf of the client's user account and authority level. This is common in a three-tier client/server model. This activity is commonly accomplished with proxy or forwarding authentication.
Top of page

Postscript

The authentication process implemented by Kerberos is highly effective, but a few hundred words cannot do the subject justice. That is why I recommend that this article be used as a primer and that you seek more in-depth technical white papers, books or consulting services prior to actual implementation. Once you understand Kerberos and how it can serve both a pure Windows 2000 and mixed operating environment then your investment should pay high dividends.

Thanks but when using the manage as option in server manager I'm specifying the remote computers local admin account so I'm not sure this article is relevant as it looks more domain specific.

I'd be interested to know if anyone else has managed to get this working, I'm guessing it's something wrong in my setup but I can't see what it is, the servers a fully patched and I've tried swtiching off the firewalls to rule that out.