Невозможно пройти проверку подлинности с использованием Kerberos Keytab и кэширования Kinit. - PullRequest
0 голосов
/ 01 июля 2019

Я использую таблицу ключей и настраиваю ее с помощью команды kinit в командной строке Windows.Я получаю сообщение «Новый тикет хранится в файле кэша». После этого, когда я запускаю свое Java-приложение для доступа к файлу keytab для ключа, я получаю сообщение об ошибке ниже.

Authentication attempt failed javax.security.auth.login.LoginException: No key to store
javax.security.auth.login.LoginException: No key to store
    at com.sun.security.auth.module.Krb5LoginModule.commit(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at javax.security.auth.login.LoginContext.invoke(Unknown Source)
    at javax.security.auth.login.LoginContext.access$000(Unknown Source)
    at javax.security.auth.login.LoginContext$4.run(Unknown Source)
    at javax.security.auth.login.LoginContext$4.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)

Я пытаюсь подключиться кактивный каталог с использованием ldap.Ниже приведены параметры конфигурации:

-Djavax.security.auth.useSubjectCredsOnly=false
-Djava.security.auth.login.config=C:\Users\cXXXXXX\Git\gssapi_jaas.conf
-Dsun.security.krb5.debug=true

Отладка - это истина storeKey - истина useTicketCache - истина useKeyTab - истина doNotPrompt - истина ticketCache - это ноль - isInitiator true - KeyTab - это

C: \ Users \ cXXXXXX \ Git \ abcd.keytab refreshKrb5Config - это ложное имя участника. xxxx_dev@xxxx.xxxxxx.COM. tryFirstPass - значение false. useFirstPass - значение false. storePass - значение false. clearPass - значение false. Получение TGT из кэша

Имя кэша KinitOptions - C:\ Users \ cXXXXXX \ krb5cc_cXXXXXX Основной клиент DEBUG - xxxx_dev@xxxx.xxxxxx.COM Основной сервер DEBUG - krbtgt/xxxx.xxxxxx.COM@Txxxx.xxxxxx.COM Тип ключа DEBUG: 23 Время отладки: понедельник, июль 14:2021 EDT 2019 Время отладки: понедельник, 01 июля 14:20:21 EDT 2019 Время отладки: вторник, 02 июля 00:20:21 EDT 2019 Время отладки: время обновления: ноль CCacheInputStream: readFlags () INITIAL;PRE_AUTH;Адрес хоста /xx.xx.xxx.xx Адрес хоста / xxx: 0: 0: 0: xxxx: xxxx: xxxx: xxxx KrbCreds обнаружил билет для выдачи билетов по умолчанию в кэше учетных данных.Имя конфигурации Java: null Собственное имя конфигурации: C: \ windows \ krb5.ini Получен TGT из LSA: учетные данные: client=sxxxx_dev@xxxx.xxxxxx.COM server=krbtgt/Txxxx.xxxxxx.COM@Txxxx.xxxxxx.COM authTime =20190701182021Z startTime = 20190701182021Z endTime = 20190702042021Z renewTill = нулевые флаги = НАЧАЛЬНЫЙ; PRE-AUTHENT EType (skey) = 23 (ключ tkt) = 18 Главный sxxxx_dev@xxxx.xxxxxx.COM

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

public static void main(String[] args) {

    // 1. Log in (to Kerberos)
    LoginContext lc = null;
    try {
        /*lc = new LoginContext(Azrm017.class.getName(),
        new LuwCallBackHandler());
*/
        lc = new LoginContext("Azrm017");
        // Attempt authentication
        // You might want to do this in a "for" loop to give
        // user more than one chance to enter correct username/password
        lc.login();

    } catch (LoginException le) {
        System.err.println("Authentication attempt failed " + le);
        le.printStackTrace();
        System.err.println("Authentication attempt failed " + le.getSuppressed());

        System.exit(-1);
    }

    // 2. Perform JNDI work as logged in subject
    NamingEnumeration<SearchResult> ne =
            (NamingEnumeration<SearchResult>) Subject.doAs(lc.getSubject(),
                new SearchAction());
    while(ne.hasMoreElements()) {
        System.out.println(">>>> : " + ne.nextElement().getName());
    }

    //Subject.doAs(lc.getSubject(), new JndiAction(args));
    }
}


/**
 * The application must supply a PrivilegedAction that is to be run
 * inside a Subject.doAs() or Subject.doAsPrivileged().
 */
class SearchAction implements java.security.PrivilegedAction {

    public Object run() {

        // Set up the environment for creating the initial context
        Hashtable<String, String> env = new Hashtable<> (11);
        env.put(Context.INITIAL_CONTEXT_FACTORY,
            "com.sun.jndi.ldap.LdapCtxFactory");
        String cn = "dn:CN=xxxxxxx,OU=Service xxxxx,OU=Accounts,OU=xxxxx,DC=test,DC=xxxxxx,DC=com";
        env.put(Context.PROVIDER_URL, "ldap://test.xxxxxxx.com:389");
        env.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");
        env.put("javax.security.sasl.server.authentication", "true");
        env.put("javax.security.sasl.qop", "auth-conf");

        DirContext ctx = null;
        try {
           // Create initial context
           ctx = new InitialDirContext(env);

           SearchControls ctls = new SearchControls();
           ctls.setReturningAttributes(
                 new String[] {"displayName", "mail","description", "suSunetID"});

           NamingEnumeration<SearchResult> answer =
                ctx.search("cn=People, dc=test, dc=xxxxxxxx, dc=com",
                                 "(&(cn=p*)(sn=s*))", ctls);

            return answer;


        } catch (Exception e) {
               e.printStackTrace();
        }
         // Close the context when we're done
        finally {
            closeContext(ctx);
        }
        return null;
    }

Прикреплено выше

1 Ответ

0 голосов
/ 18 июля 2019

Это неправильная комбинация параметров Krb5LoginModule.Если вы хотите, чтобы инициатор сохранил ключ, то этот ключ должен использоваться для получения билета (т. Е. Значение useTicketCache не должно быть истинным).

Почему вы хотите сохранить ключ?Будет ли инициатор также выступать в роли акцептора?Если да, вы должны либо использовать keytab для аутентификации (например, useTicketCache = false), либо пойти по пути ENC-TKT-IN-SKEY (т.е. storeKey = false).

...