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.

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.

Kerberos Event ID 4 - draft

Event Type: Error

Event Source: Kerberos

Event Category: None

Event ID: 4

Date: 4/18/2007

Time: 2:01:16 AM

User: N/A

Computer: computer1

Description:

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/njmail01.corpdomain.com. The target name used was COMPUTER2. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (CORPDOMAIN.COM), and the client realm. Please contact your system administrator.



Theory that needs more study to verify:



A client requested service/resource from COMPUTER2, it got ticket that had been encrypted with COMPUTER2's key. But somehow it sent the ticket to COMPUTER1, who couldn't decrypt the ticket because it didn't have correct key.



Cause: 1. DNS or other name resolution error causes the client sending ticket to wrong machine. Check if there is any wrong/duplicate A/PTR records for COMPUTER1 and COMPUTER2



2. Computer2 didn't have one of its SPNs registered. When a request for that service with respective ticket comes in, the ticket then is sent to the local computer account, which has host/SPN(or cifs/SPN) automatically created. In this case, host/SPN isn't the service that is expected, therefore the error generated.



Example: COMPUTER2 is a sql server, it should have had a sql/SPN registered for its service account, but it didn't. When a client asks for sql service from computer2, ideally the ticket should be sent to sql service but since there isn't sql/SPN record in AD, the ticket is sent to local machine account(computer2) instead. The local computer tries to use its automatically generated cifs/SPN(host/SPN) to decrypt the ticket and fails.

Microsoft Link

(search on keyword KRB_AP_ERR_MODIFIED)

LDAP search filter syntax and matching rules

http://msdn2.microsoft.com/en-us/library/aa746475.aspx

How to set up WebDav folder

SERVER SIDE

================



WebDav has to be a separate site with no host header.

1. Open the properties, go to "Web Site"\Advanced\, make sure "Host header value" is empty

2. Go to "HTTP Headers", remove all "Custom HTTP Headers"

3. The root folder will be shared as \.



To add other folders to be shared:

1. Windows Explorer

2. Open the properties of the folder, Web Sharing

3. In "Share on" dropdown list, select the website we created

4. Select "Select this folder", give it an alias





CLIENT SIDE

====================

1. Go to "My network places"

2. Add an alias

Scheduled Task won't run

When this happens I am sure you will be told to check your permissions here and there, but you are sure you have all needed permissions set perfectly. So you put yourself into google search, still, everybody talks about nothing but permissions.

And -

Here is another important thing to check: to run as a schedule tasks, the credential used must have "Log on as batch job" privilege. This will be added for you automatically when you created jobs, sweet. However, if it is removed later on with whatever reason, or overrided by Group Policy, that is when issue starts.

Interpreting Userenv.log file

https://blogs.technet.microsoft.com/askds/2008/11/11/understanding-how-to-read-a-userenv-log-part-1/

https://blogs.technet.microsoft.com/askds/2008/11/11/understanding-how-to-read-a-userenv-log-part-2/

end#

Very good exchange article collections - Exchange Insider Articles.

http://technet.microsoft.com/en-us/library/aa996113.aspx

end#