KrbException "Message Stream Modified (41)" при подключении к общему ресурсу SMB с использованием Kerberos

Question

У меня возникли проблемы с проверкой подлинности Kerberos для управления файлами с помощью JCifs (расширение Kerberos версии 1.3.17)

Это моя текущая конфигурация krb5.conf:

[libdefaults]
    default_realm = <REALM_NAME_UPPERCASE>
    udp_preference_limit = 1
[realms]
    <REALM_NAME_UPPERCASE> = {
        kdc = <DOMAIN_NAME_UPPERCASE>:88
        admin_server = <DOMAIN_NAME_UPPERCASE>
        default_domain = <DOMAIN_NAME_UPPERCASE>
    }
[domain_realm]
    .<domain_name> = <REALM_NAME_UPPERCASE>
    <domain_name> = <REALM_NAME_UPPERCASE>
[appdefaults]
    kinit = {
        renewable = true
        forwardable = true
    }

И это код проверки подлинности пользователя, а затем попытка найти файл на файловом сервере в сети:

public static void main (String[] args) throws Exception {
    Subject subject = new Subject();
    System.setProperty("java.security.krb5.conf", "C:/krb5.conf");
    System.setProperty("sun.security.krb5.debug", "true");

    Map<String, Object> state = new HashMap<String, Object>();
    state.put("javax.security.auth.login.name", "USERNAME");
    state.put("javax.security.auth.login.password", "PASSWORD".toCharArray());

    Map<String, Object> options = new HashMap<String, Object>();
    options.put("debug", "true");
    options.put("useFirstPass", "true");

    Krb5LoginModule login = new Krb5LoginModule();
    login.initialize(subject, null, state, options);

    if (login.login()) {
        login.commit();
    }

    String path = "file://HOST/242269/"; // existing file server folder
    Kerb5Authenticator kerberosAuthenticator = new Kerb5Authenticator(subject);

    SmbFile smbFile = new SmbFile(path, kerberosAuthenticator);
    SmbFile[] files = smbFile.listFiles();

    for (SmbFile file : files) {
        System.out.println(file);
    }
}

Теперь, когда я запускаю этот код, он говорит, что может аутентифицировать пользователя с этими учетными данными (когда я изменяю учетные данные, аутентификация не проходит), и он создает билет для этого пользователя. Когда я позже попытаюсь извлечь содержимое файлового каталога через CIFS, он выдаст мне следующую ошибку:

GSSException: No valid credentials provided (Mechanism level: Message stream modified (41))
at sun.security.jgss.krb5.Krb5Context.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at jcifs.smb.SpnegoContext.initSecContext(SpnegoContext.java:80)
at jcifs.smb.Kerb5Authenticator.setup(Kerb5Authenticator.java:196)
at jcifs.smb.Kerb5Authenticator.access$000(Kerb5Authenticator.java:30)
at jcifs.smb.Kerb5Authenticator$1.run(Kerb5Authenticator.java:168)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at jcifs.smb.Kerb5Authenticator.sessionSetup(Kerb5Authenticator.java:166)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:320)
at jcifs.smb.SmbSession.send(SmbSession.java:239)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:925)
at jcifs.smb.SmbFile.connect(SmbFile.java:974)
at jcifs.smb.SmbFile.connect0(SmbFile.java:890)
at jcifs.smb.SmbFile.resolveDfs(SmbFile.java:669)
at jcifs.smb.SmbFile.send(SmbFile.java:783)
at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:2009)
at jcifs.smb.SmbFile.doEnum(SmbFile.java:1758)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1735)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1668)

Вы можете найти полный журнал ошибок здесь (некоторые детали запутаны)

Может ли кто-нибудь, пожалуйста, заставить меня идти в правильном направлении относительно того, что я делаю здесь неправильно?

Answer 1

Прописные буквы очень важно избегать "Exception: krb_error 41 Message stream modified (41)".

См. http://sourceforge.net/p/spnego/discussion/1003769/thread/99b3ff67/

Answer 2

Ненавижу necrobump, но столкнулся с той же проблемой при запуске Spark и Zeppelin внутри контейнера Docker, когда мастер был удаленным кластером YARN с поддержкой Kerberos. Однако в этом случае проблема с прописными / строчными буквами имени области не возникла.

Через несколько часов я нашел эту ветку, в которой предлагается удалить следующую строку изkrb5.conf файл:

renew_lifetime = 7d

И это решило проблему. Надеюсь, это кому-то поможет.

Answer 3

Альтернативный (и лучший) ответ на удаление renew_lifetime = 7dв конфигурации, разрешая принципалу делать обновления. В CentOS 7 пример команды будет следующей:

      kadmin -p admin/[e-mail]

где я предполагаю, что admin/[e-mail] является администратором, то:

      modprinc -maxrenewlife 90day +allow_renewable [e-mail]

где я предполагаю, что принципалом службы, вызывающей проблемы, является [e-mail]; и 90day возобновлять жизнь произвольно.

Это решает проблему без удаления renew_lifetime=7d от krb5.conf файл!