Client side logs: Admin$\system32\ccm\logs
Site Server logs: SMSfolder\Logs
Management Point logs: SMS_CCM\Logs
if a MP is itself a client, the client side log will be in SMS_CCM
Tracue Utility is essential for watching SMS logs!
Search This Blog
Apr 20, 2007
What does Kerberos ticket renewable time mean to you.
1. By default a user ticket(TGT) life time is 10 hours, it can be renewed up to 7 days
2. Tickets and keys obtained from the KDC are stored in a credentials cache, an area of volatile memory protected by the LSA. The credentials cache is never paged to disk. All objects stored there are destroyed when a security principal logs off or the system is shut down.
3. If you work non-stop for more than 7 days, it doesn't mean you have to type in your password again. The LSA also keeps a copy of an interactive user's hashed password. If the user's TGT expires during a logon session, the Kerberos SSP uses the LSA's copy of the hashed password to obtain a new TGT silently, without interrupting the user's logon session. The password is not stored permanently on the computer, and the local copy is destroyed when the user's logon session is destroyed.
4. However, there are changes in the background if you leave an open logon session over 7 days limit. Changes are:
1) You will get a new ticket, obviously, in the background
2) If you have any membership changes, it will be reflected in the new ticket without having you log off/log back on.
3) User Rights Assignments change will be reflected
4) If you don't force the user to log off, which could also means he/she can have access that you don't want him/her to have because his/her ticket remains valid in its lift time.
2. Tickets and keys obtained from the KDC are stored in a credentials cache, an area of volatile memory protected by the LSA. The credentials cache is never paged to disk. All objects stored there are destroyed when a security principal logs off or the system is shut down.
3. If you work non-stop for more than 7 days, it doesn't mean you have to type in your password again. The LSA also keeps a copy of an interactive user's hashed password. If the user's TGT expires during a logon session, the Kerberos SSP uses the LSA's copy of the hashed password to obtain a new TGT silently, without interrupting the user's logon session. The password is not stored permanently on the computer, and the local copy is destroyed when the user's logon session is destroyed.
4. However, there are changes in the background if you leave an open logon session over 7 days limit. Changes are:
1) You will get a new ticket, obviously, in the background
2) If you have any membership changes, it will be reflected in the new ticket without having you log off/log back on.
3) User Rights Assignments change will be reflected
4) If you don't force the user to log off, which could also means he/she can have access that you don't want him/her to have because his/her ticket remains valid in its lift time.
What's SPN's role in Kerberos
When a client needs to access a service or resource from a target server, it goes to DC to request a Service Ticket first. Because a target server can provide more than one services, in its request, the client has to include what type of resource/service it wants, this is done by including SPN in the request.
So it's easy to understand that, in an AD environment, servers(namely services providers) have to registered their SPN properly in AD in order to advertise/provide services properly. For example, Exchange server will normally register exchangeAB, exchangeMDB, exchangeRFR, and SMTP SPNs. Likewise, DC will register ldap, ntfrs, etc.
There are a few special SPNs that all servers will register automatically. HOST is one of them, sometimes in the form of cifs.
When the KDC gets a Service Ticket Request from a client, it extracts the SPN from the request, locate the server in its database(in Windows world, it's AD) based on SPN. KDC then prepares the ticket, encrypted it with the resource server's master key or service account's master key, and returns the ticket to client.
Kerberos error KRB_APP_ERR_MODIFIED (in Event ID 4 for AD) will occur if a service ticket was encrypted with one key while to be decrypted with another. This happens when a ticket is sent to a wrong computer, which in turn is often caused by duplicated DNS records, different computers have same name, etc. It can also be caused in the following scenario:
Target server (named DesiredServer)provides a service named "serviceA"; serviceA is running a service account named "ServiceAaccount"
Ideally, SPN 'serviceA\Targetserver' should be registered under DesiredServer's name. However in our example, it was registered under a different server's name, say, "WrongServer". Or same SPN 'serviceA\Targetserver' was registered twice under both "DesiredServer" and "WrongServer"
A client is requesting serviceA, it applies the service ticket from a DC with SPN 'serviceA' specified
DC searches its database based on SPN provided. It gets "WrongServer" as result. DC encrypts the ticket with "WrongServer"'s master key
The ticket is still sent to "DesiredServer" for service, and "DesiredServer" won't be able to decrypted the ticket.
A Kerberos error is logged on "DesiredServer"
Or there are chances that, when a ticket should be encrypted with a service account's key, but instead, it is encrypted with the computer's master key.
So it's easy to understand that, in an AD environment, servers(namely services providers) have to registered their SPN properly in AD in order to advertise/provide services properly. For example, Exchange server will normally register exchangeAB, exchangeMDB, exchangeRFR, and SMTP SPNs. Likewise, DC will register ldap, ntfrs, etc.
There are a few special SPNs that all servers will register automatically. HOST is one of them, sometimes in the form of cifs.
When the KDC gets a Service Ticket Request from a client, it extracts the SPN from the request, locate the server in its database(in Windows world, it's AD) based on SPN. KDC then prepares the ticket, encrypted it with the resource server's master key or service account's master key, and returns the ticket to client.
Kerberos error KRB_APP_ERR_MODIFIED (in Event ID 4 for AD) will occur if a service ticket was encrypted with one key while to be decrypted with another. This happens when a ticket is sent to a wrong computer, which in turn is often caused by duplicated DNS records, different computers have same name, etc. It can also be caused in the following scenario:
Target server (named DesiredServer)provides a service named "serviceA"; serviceA is running a service account named "ServiceAaccount"
Ideally, SPN 'serviceA\Targetserver' should be registered under DesiredServer's name. However in our example, it was registered under a different server's name, say, "WrongServer". Or same SPN 'serviceA\Targetserver' was registered twice under both "DesiredServer" and "WrongServer"
A client is requesting serviceA, it applies the service ticket from a DC with SPN 'serviceA' specified
DC searches its database based on SPN provided. It gets "WrongServer" as result. DC encrypts the ticket with "WrongServer"'s master key
The ticket is still sent to "DesiredServer" for service, and "DesiredServer" won't be able to decrypted the ticket.
A Kerberos error is logged on "DesiredServer"
Or there are chances that, when a ticket should be encrypted with a service account's key, but instead, it is encrypted with the computer's master key.
Subscribe to:
Posts (Atom)