Назад | Перейти на главную страницу

Аутентификация в режиме ядра: ошибка 401 при доступе к сайту с удаленных машин

У меня есть несколько классических сайтов ASP, которые используют встроенную проверку подлинности Windows и делегирование Kerberos.

Они нормально работают на действующих серверах (недавно переехали на серверы Server 2008 / IIS7), но не работают полностью на моем компьютере разработки или моем сервере разработки. IIS на обеих машинах был настроен с помощью пакета инструментов веб-развертывания IIS, который был экспортирован со старого компьютера; развертывание не сработало идеально, и мне пришлось немного повозиться, чтобы сайты заработали.

При доступе к приложениям локально на любом компьютере они работают нормально; при доступе с другого компьютера пользователю предлагается диалоговое окно имени пользователя / пароля, и независимо от того, что вы вводите, в конечном итоге это приводит к 401 (неавторизованный) ошибка.

Я попытался сравнить конфигурацию этих машин с аналогичными действующими серверами (которые все работают нормально), и они кажутся в целом сопоставимыми (учитывая, что ни один из действующих серверов еще не работает на IIS7.5 (Windows 7 / Server 2008 R2).

Эти приложения работают в общем пуле приложений, который использует в качестве идентификатора специального пользователя домена - этот пользователь имеет аналогичные разрешения на рабочих машинах и машинах для разработки. На платформах IIS6, чтобы включить делегирование Kerberos, мне нужно было настроить некоторые SPN для этого пользователя, и они все еще существуют (хотя я не считаю, что они больше нужны для IIS7 + из-за аутентификации в режиме ядра),

Кроме того, эта учетная запись включена для делегирования Kerberos в Active Directory, как и каждая машина, с которой я имею дело.

Я рассматриваю возможность того, что при развертывании могли быть внесены изменения / не удалось внести изменения в конфигурацию IIS, что вызвало эту проблему. Возможно, полная перестройка (без еще одной попытки веб-развертывания) решит проблему, но я бы предпочел исправить (чтобы понять) текущую проблему.

Есть идеи на данный момент?

Я только что предпринял еще одну попытку исправить эту проблему, и я добился некоторого прогресса, но у меня нет полного исправления ... пока.

Я обнаружил, что если я обращаюсь к сайтам через IP-адрес (а не через имя NetBIOS), я получаю тот же диалог, за исключением того, что он принимает мои учетные данные, и, таким образом, приложение работает - не совсем исправление, но полезный шаг.

Что еще более интересно, я обнаружил, что если я отключу аутентификацию в режиме ядра (в Диспетчер IIS> Веб-сайт> Проверка подлинности> Расширенные настройки), приложения работают отлично. Мое туманное понимание состоит в том, что это эффективно работает до IIS7 способом. Разумное краткосрочное решение, но примите во внимание следующий явный совет от IIS по этой проблеме:

По умолчанию IIS включает проверку подлинности в режиме ядра, что может повысить производительность проверки подлинности и предотвратить проблемы с проверкой подлинности в пулах приложений, настроенных на использование настраиваемого удостоверения. Рекомендуется не отключать этот параметр, если в вашей среде используется проверка подлинности Kerberos и пул приложений настроен на использование настраиваемого удостоверения.

Понятно, что мои приложения должны работать не так. Так в чем же проблема?

Я боролся с этой проблемой уже несколько лет. Периодически мне удается заставить его работать, но год спустя происходит перенос сервера, и мне снова приходится сражаться, чтобы заставить его работать на новом сервере.

Такое время снова пришло ... После попыток отладить эти проблемы с Kerberos я вернулся к основам: другие люди, должно быть, обычно делали то, что я пытался - что они использовали?

Хотя есть люди, использующие мою технику, у них явно не было проблем, а у меня. Но есть дюжина способов решить большинство проблем, поэтому я объединил методы, найденные в 2 или 3 примерах в Интернете, и разработал другой подход, который кажется более надежным и не более сложным, чем мой предыдущий, и, что очень важно, не участвовал в печально известном двойном прыжке Kerberos:

Sub Authuser()

'Swap out values enclosed in []

If Session("UID") = "" or 1 then
    Dim rsUser, aUserID, aGroups, i
    Dim connAD, sBase, sFilter, sAttributes, sScope, sFullCommand, rsADUserInfo, oADSysInfo

    aUserID = Split(Request.servervariables("AUTH_USER"),"\")

    Set connAD = Server.CreateObject("ADODB.Connection")
    connAD.Provider = "ADsDSOObject"
    connAD.Properties("User ID") = "[MyDomain]\[MyDomainUser]" ' ### remember to make sure this user has rights to access AD
    connAD.Properties("Password") = "[password]"
    connAD.Properties("Encrypt Password") = true
    connAD.Open

    sBase = "<LDAP://DC=[MyDomain], DC=[MyDomainExt]>"
    sFilter = "(sAMAccountName=" & aUserID(1) & ")"
    sAttributes = "cn, mail, company, givenName, sn, ADsPath, name, sAMAccountName, telephoneNumber, memberof"
    sScope = "subtree"  
    sFullCommand = sBase & ";" & sFilter & ";" & sAttributes & ";" & sScope

    set rsUser = Server.CreateObject("ADODB.Recordset")
    set rsUser = connAD.Execute(sFullCommand)

    If not rsUser.EOF then
        Session("UID") = aUserID(1)
        Session("Name") = rsUser("cn")
        Session("Email") = rsUser("mail")
        If IsArray(rsUser.Fields(9)) Then
            aGroups = rsUser.Fields(9)
            For i = LBound(aGroups) To UBound(aGroups)
                If InStr(1, aGroups(i), "[MyUsersGroup]", 1) Then
                    Session("Auth") = 1
                End If
                If InStr(1, aGroups(i), "[MyAdminGroup]", 1) Then
                    Session("Admin") = 1
                End If
            Next
        Else
            Response.Write "No groups<BR>"
            Session("Auth") = 1
            Session("Admin") = 1
       End If
    Else 
        Response.Write "User not recognised in AD<br>"
    End if

    connAD.Close
    set rsUser = Nothing
    Set connAD = Nothing
End If

End Sub

Попробуйте использовать другой браузер, например Chrome, если вы сейчас используете IE. Возможно, это от доменного имени, находящегося в интрасети или доверенной зоне. Это может привести к тому, что он попытается сохранить учетные данные, которые могут не работать удаленно, в зависимости от того, приходите вы из-за пределов домена или нет.