Questions[digest](server)

It seems like this should be easy. I run "ssh-keygen -l -f " (the default seems to be SHA1). All of the examples show it printing the hex-formatted digest with a little extra, harmless information. Yet, on my Mac I'm getting a useless, opaque string.

I should mention that the "-E" parameter works on Mac (10.10) but is unavailable in Ubuntu (14.04). Keep that in mind if it doesn't work for you.

$ ssh-keygen -l -E md5 -f dustin.pem
2048 MD5:29:ed:da:d3:5a:8c:78:4f:62:d3:fd:0c:77:5b:6d:d9 dustin.pem.pub (RSA)

$ ssh-keygen -l -E sha1 -f dustin.pem
2048 SHA1:x2ENPL+vzVdlgkIyu0tAhVQ+H4U dustin.pem.pub (RSA)

$ ssh-keygen -l -E sha256 -f dustin.pem
2048 SHA256:agJs/axI8QPzet/eoPMDxLSf37fd1bgsMX4Di0gqMy4 dustin.pem.pub (RSA)

Both of the attempted SHA algorithms return opaque, but different, ASCII strings.

What am I missing? How do I get a SHA1 hex-digest without having to copy my key to a Linux system to do it?

Thanks.

I'm able to authenticate using AD credentials and the requested page loads fine, but IIS is re-requesting authentication for every page change or page refresh.

If this is normal behavior for this type of authentication, what would be a better way to authenticate to prevent requesting of credentials for every page change/refresh?

I've setup a very simple test application with page1.html that has a link to page2.html. When clicking the link to page2, I'm asked again for credentials. I created a folder called test1 and in the IIS Manager I did a "Convert to application" using the DefaultAppPool. I disabled Anonymous Authentication and enabled Digest Authentication, and removed the default Authorization Rule and added an Allow for mydomain\testgroup, all from the IIS Manager.

The directory structure is:

c:\inetpub\wwwroot\test1
------------------- page1.html
------------------- page2.html
------------------- web.config

And the contents of the web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <authorization>
                <remove users="*" roles="" verbs="" />
                <add accessType="Allow" roles="mydomain\testgroup" />
            </authorization>
        </security>
    </system.webServer>
</configuration>

UPDATE: If I toggle the Authentication method from Digest to Basic, everything works as it should and I can navigate between the pages in the application. Why is Digest causing it to ask for credentials each page change?

I have a development copy of an ASP.NET intranet site checked out and running on my local machine. We're using digest authentication to allow users to log in using their active directory accounts.

On my development copy only, Digest sometimes will repeatedly prompt for login information usually ~9 times per page request. After repeatedly logging in (or it also works to cancel out of 8 out of the 9 prompts), I can use the site as normal.

I cannot pinpoint what is triggering the issue. Sometimes this problem triggers upon the next page request, sometimes after I edited/saved/refreshed a page, and sometimes it doesn't happen at all.

Each prompt triggers several logon (Event ID 4624 & 4672) security events in the Events Viewer. Shortly after each burst of logon events, I'll see a burst of logoff events (Event ID 4634)

A co-worker who has a nearly an identical setup (Windows 7, IIS 7) is not experiencing the issue. Our production copy (that is running on a different server) also does not experience the issue. We've tried to compare our settings in IIS, not really finding any differences.

I'm using chrome but I've experienced the issue in other browsers.

I'm using IIS 7 Digest authentication to control access to a certain directory containing files. Users access the files through a department website from inside our network and outside. I've set NTFS permissions on the directory to allow a certain AD group to view the files. When I click a link to one of those files on the website I get prompted for a username and password. With most users everything works fine, but with a few of them it prompts for a password 3 times and then get:

401 - Unauthorized: Access is denied due to invalid credentials.

But other users that are in the group can get in without a problem. If I switch it over to Windows Authentication, then the trouble users can log in fine. That directory is also shared, and users that can't log in through the website are able to browse to the share and view files in it, so I know that the permissions are ok.

Here's the portion of the IIS log where I tried to download the file (/assets/files/secure/WWGNL.pdf):

2010-02-19 19:47:20 xxx.xxx.xxx.xxx GET /assets/images/bullet.gif - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 200 0 0 218
2010-02-19 19:47:20 xxx.xxx.xxx.xxx GET /assets/images/bgOFF.gif - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 200 0 0 218
2010-02-19 19:47:21 xxx.xxx.xxx.xxx GET /assets/files/secure/WWGNL.pdf - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 401 2 5 0
2010-02-19 19:47:36 xxx.xxx.xxx.xxx GET /assets/files/secure/WWGNL.pdf - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 401 1 2148074252 0
2010-02-19 19:47:43 xxx.xxx.xxx.xxx GET /assets/files/secure/WWGNL.pdf - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 401 1 2148074252 15
2010-02-19 19:47:46 xxx.xxx.xxx.xxx GET /manager/media/script/_session.gif 0.19665693119168282 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 200 0 0 203
2010-02-19 19:47:46 xxx.xxx.xxx.xxx POST /manager/index.php - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 200 0 0 296
2010-02-19 19:47:56 xxx.xxx.xxx.xxx GET /assets/files/secure/WWGNL.pdf - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 401 1 2148074252 15
2010-02-19 19:47:59 xxx.xxx.xxx.xxx GET /favicon.ico - 80 - 10.5.16.138 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US)+AppleWebKit/532.5+(KHTML,+like+Gecko)+Chrome/4.0.249.89+Safari/532.5 404 0 2 0

Here's the Failed Logon attempt in the Security Log:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          2/19/2010 11:47:43 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      WEB4.net.domain.org
Description:
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       jim.lastname
    Account Domain:     net.domain.org

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xc000006d
    Sub Status:     0xc000006a

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   -
    Source Network Address: 10.5.16.138
    Source Port:        50065

Detailed Authentication Information:
    Logon Process:      WDIGEST
    Authentication Package: WDigest
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4625</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2010-02-19T19:47:43.890Z" />
    <EventRecordID>2276316</EventRecordID>
    <Correlation />
    <Execution ProcessID="612" ThreadID="692" />
    <Channel>Security</Channel>
    <Computer>WEB4.net.domain.org</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-0-0</Data>
    <Data Name="TargetUserName">jim.lastname</Data>
    <Data Name="TargetDomainName">net.domain.org</Data>
    <Data Name="Status">0xc000006d</Data>
    <Data Name="FailureReason">%%2313</Data>
    <Data Name="SubStatus">0xc000006a</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">WDIGEST</Data>
    <Data Name="AuthenticationPackageName">WDigest</Data>
    <Data Name="WorkstationName">-</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">-</Data>
    <Data Name="KeyLength">0</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">10.5.16.138</Data>
    <Data Name="IpPort">50065</Data>
  </EventData>
</Event>

So I have two domains, both use the same htdigest settings and password, etc. The problem is that it doesn't use the same auth over on the other one. My two htdigest locations are: http://svn.kylehotchkiss.com and http://apps.kylehotchkiss.com/codex. Here is the config for my svn.kylehotchkiss.com domain:

 <Directory />
  DAV svn
  SVNParentPath /srv/svn.kylehotchkiss.com/repo
  SVNListParentPath On

  AuthType Digest
  AuthName "KHP Code Repository"
  AuthDigestDomain / http://svn.kylehotchkiss.com/ http://apps.kylehotchkiss.com/codex/
  AuthDigestProvider file
  AuthUserFile /srv/svn.kylehotchkiss.com/auth/passwd
  Require valid-user
 </Directory>

and my code for the apps.kylehotchkiss.com/codex/ is in a .htaccess file there and this is how it goes:

AuthType Digest
AuthName "KHP Code Repository"
AuthDigestDomain / http://apps.kylehotchkiss.com/codex/ http://svn.kylehotchkiss.com/
AuthDigestProvider file
AuthUserFile /srv/svn.kylehotchkiss.com/auth/passwd
Require valid-user

So what exactly am I missing with the AuthDigestDomain settings that doesn't allow the two to work together? Is the .htaccess file in the wrong spot?