Password protected Excel file – Prompt Twice for password for Copy & Original

Issue:

I recently noticed every time I open a password protected file in Excel 2010 it prompts for a password for the original file and a password to open a separate copy of the same file! If I want to open a password protected file called for example "Books.xlsx" the dialog box pops up to enter my password then another dialog box pops up asking me to enter password for "copy of Books.xlsx also (the copy of file is whatever name your original file name is with the words "copy of" in front) It happens on all my password protected files. This is rather new for me I have been password protecting files in Excel for the last four versions of office and have never seen this before. I think it is related to a new update or something because the same thing happens on my laptop. I am running Windows 7 and Office 2010 home and business on both computers. Please help! It’s kind of scary!

Resolution:

The preview pane essentially opens a new instance of the Application, in order to ‘show’ the file.
You can quickly toggle the preview pane display ON/OFF with [Alt] P
although you could have a routine which tells whether an Excel file is password-protected or not, it would be difficult to have this operate with the preview pane.

AD Slow Authentication and prompting for credentials again and again

It’s a most common issue in a complicated Active Directoryenvironment, before am going to discuss about the authentication issues, I would like to discuss about the Active Directory basics like Pass throughauthentication, AD secure channel, NTLM and Kerberos

Pass through authentication

If you are worked on multi Domain/Forest environment or environment designed with user forest and resource forest, an Exchange Serverresource forest topology has two forests. One forest contains the all the user accounts for your organization. This forest is called the user forest (accounts forest). The other forest does not contain any user accounts. It only contains the Exchange Server and disabled user accounts, in simple you have one Active Directory forest where your user accounts live and another Active Directoryforest where your application are lives (Exchange server, File server)

In the above scenario Domain controller receiving the request from Exchange/file server to verify the user access, this must pass the request to Domain controller in the user forest, we should have the trust between domain of the server (called the resource domain/forest) and the domain of the user account (called the account domain/forest)

User from Domain A try to access application on server from Domain B, application server in Domain B doesn’t have user detail, it will check the local Domain controller on Domain B through workstation secure channel, and Domain controller on Domain B check the Domain controller on Domain A through trusted domain secure channel and Domain A return back theauthentication to Domain B it’s called the pass through authentication since the user authentication request been passed to user domain.

Secure Channel

I have discussed about the secure channel, what is secure channel? It’s a communication channel provides more secure communication path between the domain controller and the workstations or member servers. It can also be used to retrieve domain-specific information, handling NTLMauthentication pass-through to the domain controller or from DC to DC for the same.

Two Forest or Domain connected through Forest trust / Domain trust, trust establishment is a shared secret (called a trust password) that domain controller use in the two domains for computing the session key that is used for protecting the secure channel traffic. By using this secure channel, the DC in the resource domain can pass logon requests securely to the DC in the account domain, in the same way that the server passed the logon request to the former DC. The secure channel between DCs in two domains that are connected via a trust relationship is called a trusted domain secure channel. In contrast, the secure channel between the member server and the DC in the resource domain is called a workstation secure channel

While adding a computer to domain, computer account has been created in Activity directory and password been generated for computer account, computer account password been changed every 30 day’s and stored in computer and domain controller, while power on the computer, Netlogon service on computer use the computer account password from the computer is authenticated against the password on the Domain Controller and establishes a secure channel with that DC, same way server creates a secure channel with that DC it get authenticated

For Domain controller, Netlogon service sets up secure channels with all the trusted domains (one Domain controller in each trusted domains) you can check this using Nltest command

To check the current secure channel with a particular Domain

nltest /sc_query:Domain Name

To reset secure channel to different Domain Controller (this will randomly select the Domain Controller)

nltest /SC_RESET: Domain Name

To reset secure channel to a particular Domain Controller

nltest /SC_RESET: Domain Name\ Domain Controller Name

You can change the Domain and Domain Controller Name as per your requirement

For remote server you can add

/server: server name

NTLM and Kerberos

NTLM and Kerberos are the protocols used for authentication, we all know NTLM is outdated and Kerberos is the new protocols used forauthentication, Kerberos can impersonate a user when trusted, so no need to contact Domain controller every time in order to authenticate access to a resource, If the client is logged on to a domain, the browser never prompts the user for credentials; it simply uses the user’s default logon credentials.

We are not using NTLM any more? No still some areas where we have to use NTLM for the sake of compatibility, RPC over HTTP to connect to an Exchange mailbox. ISA for web proxy servers, let’s go in deep how it’s works

Client opens a URL through browser

Client browser sent a request to proxy server with integrated authentication credentials

The proxy server needs to verify the user credentials, by sending the authentication request to the domain controller is has a secure channel

That domain controller responds to the proxy server

The proxy server answers the client with the requested internet page

Seems to be simple however for each web connection from a client, the proxy server needs to verify the user credentials by sendingauthentication request to the DC, this will increase the high volume of NTLMauthentication

Think the similar scenario in multi Domain/Forest environment, user in one Forest and proxy server in other Forest, this will increase the NTLM Pass through authentication traffic

NTLM authentication handled by Netlogon service, passing NTLM authentication requests to a domain controller that can handle them, and receiving them on that domain controller to be handled, you can enable debug logging for the Net Logon service to see what happen on the proxy server / domain controller, like which user getting authenticated to which domain controller

We have number of threads which will authentication request, like number of concurrent NTLM authentications processed by the server, the defaults are typically 1 for this, meaning that there is one thread to hand off, receive and process these requests, we can re-configure this through MaxConcurrentApi

The MaxConcurrentApi thread can only deal with oneauthentication at a time, in normal scenario it is very quick. So the high volume of authenticationtransactions must be handled by one or two threads (by default) and this will be a bottleneck, which resulting the delay and the authentication request have to wait longer than a remote client can tolerate

Due to this delay, client browser would ask for a credential prompt rather than the web page he want to open, so this might be the issue for slow Authentication and prompted for credentials again and again

We can resolve this by increasing the MaxConcurrentApi value on proxy server, if it’s a multi Domain/Forest environment, then we needs to increase the MaxConcurrentApi value on resource forest Domain Controller, it depends on the configuration

First we have to understand current issue

Enable the Netlogon logs on proxy server and Domain Controller authenticating proxy server or the proxy server secure channelled Domain Controller

Analysis the log for authentication failure and delay

We can monitor the current secure channel traffic through the perfmon by adding the counters, Semaphore Waiters, Semaphore Holders, Semaphore Acquires, Semaphore Timeouts, Average Semaphore Hold Time

Logon to Domain Controller authenticating proxy server

Open perfmon, add counters – select Netlogon on performance object

And select Average Semaphore Hold Time

If you don’t find the counters, need to installhttp://support.microsoft.com/kb/928576 hot fix, this adds New performance counters for Windows Server 2003

If the Average Semaphore Hold Time is greater than normal, Average Semaphore Hold Time should normally be very quick. Longer hold times mean that a potential bottleneck is occurring, it will delay authenticationprocess and the authentication request has to wait longer than a remote client can tolerate, it will slowdown the authentication and prompted for credentials to re-initiate the authentication process

To calculate MaxConcurrentApi for your environment

http://support.microsoft.com/kb/2688798

It depends on the outcome, you should add more servers to service the legacy authentication load or increase the MaxConcurrentApi registry value

Warning rules:

Average Semaphore Hold Time > 0.2 should be a yellow warning.

Average Semaphore Hold Time > 0 should be a red warning.

Semaphore waiters > 1 should be a yellow warning.

Semaphore waiters> 4 should be a red warning.

Any Semaphore Timeouts is a red warning.

Conclusion:

Slow Authentication might be due to many issues, like client to DC connectivity, network, subnet and site configuration, DNS SRV configuration, Profile, logon script and GPO, so you have to analysis properly to find the root case, this is the one of the scenarios which I have faced many times in a complex environment, hope this will help you to understand the Active Directory Authentication and troubleshooting procedures see you soon in an another article.

Source:

http://www.windowstricks.in/2013/12/ad-slow-authentication-and-prompting.html

Active directory Troubleshooting (Part1 – Diagnostics Logging)

Troubleshooting Active Directory issues like authentication failures, performance issues and logon issues, we can use different methods to monitor the AD, I will discuss more about enabling diagnostics logging, adding related counters on performance monitor to monitor the AD, Enabling debug logging for the Net Logon service

As an Active Directory Administrator did any one asked the questions like, how many search operations Active Directory performed and who searched from which server? Number of secure channel connection to which Domain and Domain controller? Number of Kerberos authentications on the server per second? Number of connected LDAP client sessions

While doing the troubleshooting you may have this question or some one asked the question to resolve the issue, am going discuss how to find the answer for this

Active Directory Diagnostics logging

To get more data about the directory service we have to enable Active Directory Diagnostics logging to respective Domain controllers in the registry (HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\)

We have below values in Diagnostics logging, when enabled, it will dump additional events into the DC event log to assist with troubleshooting. You can change these values from zero to five, the default value is zero, meaning minimal verbosity, and a setting of five will dump more than you want, normally I use four (if require five)

Note: Make sure to reset the value to zero when troubleshooting is completed

The most common values for Active Directory Diagnostics logging:

• 1 Knowledge Consistency Checker
• 10 Performance Counters
• 13 Name Resolution (this is DNS related)
• 15 Field Engineering
• 18 Global Catalog
• 2 Security Events
• 5 Replication Events
• 8 Directory Access
• 9 Internal Processing

I have used 15 Field Engineering value many times to find the inefficient LDAP queries including the client who was the source of the query with query string and the root of the query. This is important because one of the headaches related to AD is the LSASS process (Local System Authority Subsystem Service) using up enough resources to hang or crash a DC and cause client log on delays. Inefficient LDAP queries by a user or by an application or Linux client log on will put a huge load on LSASS. Enabling this diagnostic log will quickly identify the affected system or IP address in your network that casing the problem, so you will know which system searching the AD (querying the info from AD) and what info the system searching, this will help you to find the root cause of the issue, it helped me in many occasions

Example Events:

You will receive Event ID: 1643 if the value of 15 Field Engineering set to 4

Event Type: Information
Event Source: NTDS General
Event Category: Field Engineering
Event ID: 1643
Date: 28/05/2012
Time: 1:35:26 p.m.
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: server1
Description:

Internal event: Active Directory performed the following number of search operations within this time interval.

Time interval (hours):
12

Number of search operations:
30937

During this time interval, the following number of search operations were characterized as either expensive or inefficient.

Expensive search operations:0

Inefficient search operations:0

You will receive Event ID: 1644 if the value of 15 Field Engineering set to 5

If you set the value to 5 you will see an event entry for each search against the directory that breaches the inexpensive and/or inefficient search thresholds.

Event Type: Information
Event Source: NTDS General
Event Category: Field Engineering
Event ID: 1644
Date: 28/05/2012
Time: 10:06:25 a.m.
User: TM\Administrator
Computer: server1
Description:
Internal event: A client issued a search operation with the following options.

Client:
192.168.100.1

Starting node:
DC=test,DC=com

Filter: ( & (objectClass=user) (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=test,DC=com) (sn=z*) )

Search scope:

subtree

Attribute selection:

sAMAccountName

Server controls:

Visited entries:

24579

Returned entries:

25

For more information, see Help and Support Center athttp://go.microsoft.com/fwlink/events.asp.

Conclusion:

But you won’t actually see anything in the event log until you have enabled diagnostics logging by modifying the registry.

Like that for replication troubleshooting, you can enable 1 Knowledge Consistency Checker and 5 Replication Events, The 9 Internal Processing value is for getting additional details for DS events that indicate an internal error has occurred. This will often cause additional events that will aid in diagnosing the problem

Come back to see the next part of Active Directory Troubleshooting article, hope this will help you

Source:

http://www.windowstricks.in/2013/06/active-directory-troubleshooting-part1.html