Weblogic Kerberos

Weblogic установлен на сервере budwf
Домен контролер wcctst.wcc.local
Клиентская винда XZ

1. Генерим keytab

ktpass -princ HTTP/srv_budwf@WCC.LOCAL -mapuser srv_budwf -kvno 0 -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass lalal_1 -out c:\temp\budwf.keytab

Т.е в данном случае principal name в keytab полностью соответствует ожиданиям...

C:\Users\Administrator>ktpass -princ HTTP/srv_budwf@WCC.LOCAL -mapuser srv_budwf -kv
no 0 -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass lalal_1 -out c:\temp\b
udwf.keytab
Targeting domain controller: wcctst.wcc.local
Successfully mapped HTTP/budwf to srv_budwf.
Password succesfully set!
Key created.
Output keytab to c:\temp\budwf.keytab:
Keytab version: 0x502
keysize 55 HTTP/budwf@WCC.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x11 (AE
S128-SHA1) keylength 16 (0xbf005ae14d58153abe3eab57cf5a8260)

C:\Users\Administrator>setspn -L srv_budwf
Registered ServicePrincipalNames for CN=srv_budwf,CN=Users,DC=wcc,DC=local:
        HTTP/srv_budwf

C:\Users\Administrator>setspn -S HTTP/budwf srv_budwf
C:\Users\Administrator>setspn -S HTTP/budwf.wcc.local srv_budwf

Это в принципе похуй но можно выполнить...

C:\Users\Administrator>setspn -D HTTP/srv_budwf srv_budwf

Да пока вспомнил для корректной работы с типом шифрования AES128-SHA1 у пользователя
srv_budwf должна быть соответствующая "галочка":

2. На linux сервере с Weblogic
[01:14:32] oracle@budwf:~ $ cat /etc/krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = WCC.LOCAL 
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

 default_tgs_enctypes = aes128-cts
 default_tkt_enctypes = aes128-cts
 permitted_enctypes = aes128-cts
 clockskew = 300


[realms]
 WCC.LOCAL = {
  kdc = wcctst.wcc.local
  admin_server = wcctst.wcc.local
  default_domain = wcc.local
 }

[domain_realm]
 .wcc.locac = WCC.LOCAL
 wcc.local = WCC.LOCAL

3. Необходимо создать в домене weblogic файл вида:
[01:11:33] oracle@budwf:/opt/oracle/middleware/user_projects/domains/budwf_domain$ cat krb5Login.conf
com.sun.security.jgss.initiate {
  com.sun.security.auth.module.Krb5LoginModule required 
  principal="HTTP/budwf@WCC.LOCAL"
  useKeyTab=true
  keyTab=budwf.keytab
  storeKey=true 
  debug=true;
};

com.sun.security.jgss.krb5.accept {
  com.sun.security.auth.module.Krb5LoginModule required
  principal="HTTP/budwf@WCC.LOCAL"
  useKeyTab=true 
  keyTab=budwf.keytab
  storeKey=true 
  debug=true;
};

т.е в моём случае всё будет храниться в директории
/opt/oracle/middleware/user_projects/domains/budwf_domain.

Если вы решили использовать другую директрию то в ServerStart:
-Djava.security.auth.login.config=/opt/oracle/user_projects/domains/budwf_domain/kerberos/krb5Login.conf 

И keytab должен быть в кавычках т.е:
krb5Login.conf
com.sun.security.jgss.initiate {
  com.sun.security.auth.module.Krb5LoginModule required 
  principal="HTTP/budwf@WCC.LOCAL"
  useKeyTab=true
  keyTab="/opt/oracle/user_projects/domains/budwf_domain/kerberos/budwf.keytab"
  storeKey=true 
  debug=true;
};

com.sun.security.jgss.krb5.accept {
  com.sun.security.auth.module.Krb5LoginModule required
  principal="HTTP/budwf@WCC.LOCAL"
  useKeyTab=true 
  keyTab="/opt/oracle/user_projects/domains/budwf_domain/kerberos/budwf.keytab"
  storeKey=true 
  debug=true;
};

4. Копируем с DC сгенерённый keytab на linux в директорию /opt/oracle/middleware/user_projects/domains/budwf_domain

5. Стартуем weblogic.
Предположим что приложение будет крутится на сервере budwf_1
Соответственно в ServerStart надо сделать следующие настройки:

-Xms1024M -Xmx1024M -Xrs -Dsun.security.krb5.debug=true -Djava.security.krb5.realm=WCC.LOCAL -Djava.security.krb5.kdc=wcctst.wcc.local -Djava.security.auth.login.config=/opt/oracle/middleware/user_projects/domains/budwf_domain/krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false

Или кошерней я считаю такие (что бы все настройки брались из /etc/krb5.conf):
-Xms6G -Xmx6G -XX:MaxPermSize=1024M -Xmn3G -Xrs -Dsun.security.krb5.debug=true -Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=/opt/oracle/user_projects/domains/budwf_domain/krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dcom.sun.jndi.ldap.read.timeout=10000  -Djava.awt.headless=true -Dweblogic.security.enableNegotiate=true

6. Рестартаем budwf1
7. Деполим тестовую пркладуху

Про саму прикладуху и её настройки можно прочитать в конце поста...

8. Firefox about:config
network.negotiate-auth.trusted-uris: http://,https://

9. Добавить в weblogic пару провадйеров типа самого AD а так же NegotiateIdentityAsserter в падлу писать как это делать там и так всё понятно поидее. NegotiateIdentityAsserter должен быть первый! или virtualize true (наверное)

10. проверяем что получилось предварительно запустив wireshark на клиентской винде.

Если что то пошло не так:
1. На клиентской винде выполнить команду
klist purge

2. Открываем браузер чистим на хер все куки и т.д

4. Переходим на тестовую прикладуху в браузере:

3. Открываем wireshark и смотрим ошибки, одна из самых распространённых:
krb5kdc_err_s_principal_unknown

Вся хуйня в том что сервер резоливится с доменом решение на домен контролере выполнить
setspn -S HTTP/budwf.WCC.LOCAL  srv_budwf

Тестовая прикладуха

Самая ахуенная прикладуха находится в ноте 1332241.1

Правда перед тем как её деплоить необходимо произвести некоторые настройки.
Собственно авторизацией продолжает заниматься weblogic. Так что надо подредактировать пару файлов а именно:
weblogic.xml
web.xml

1. Разархивируем приложение ssotestwebapp.war в папку SSOTest например

[oracle@oracleadmintst SSOTest]$ ls -la *

-rw-r--r-- 1 oracle oinstall  372 Jun 13  2011 index.jsp

WEB-INF:

total 16

drwxr-xr-x 2 oracle oinstall 4096 Feb 28 12:51 .

drwxr-xr-x 3 oracle oinstall 4096 Feb 28 12:51 ..

-rw-r--r-- 1 oracle oinstall  450 Feb 28 12:51 weblogic.xml

-rw-r--r-- 1 oracle oinstall  844 Feb 25 14:23 web.xml

2. Идем в WEB-INF

3. Тут отмечу все важные строки:

[oracle@oracleadmintst WEB-INF]$ cat weblogic.xml 

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">

<weblogic-web-app>

<security-role-assignment>

<role-name>Admin</role-name>

<principal-name>Administrator</principal-name>

<principal-name>PDegtyarev</principal-name>

</security-role-assignment>

<context-root>ssotest</context-root>

</weblogic-web-app>

[oracle@oracleadmintst WEB-INF]$ cat web.xml 

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

  <welcome-file-list>

    <welcome-file>index.jsp</welcome-file>

  </welcome-file-list>

  <security-constraint>

<display-name>Security Constraint for SSO </display-name>

<web-resource-collection>

<web-resource-name>My webapp</web-resource-name>

<description>Group of Users</description>

<url-pattern>/*</url-pattern>

<http-method>GET</http-method>

<http-method>POST</http-method>

</web-resource-collection>

<auth-constraint>

<role-name>Admin</role-name>

</auth-constraint>

</security-constraint>

<login-config>

<auth-method>CLIENT-CERT</auth-method>

</login-config>

<security-role>

<description>Role description</description>

<role-name>Admin</role-name>

</security-role>

</web-app>

соответственно в weblogic.xml <principal-name>PDegtyarev</principal-name>

Что бы работало для все пользователей weblogic.xml:

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">

<weblogic-web-app>

<security-role-assignment>

<role-name>Admin</role-name>

<principal-name>users</principal-name>

</security-role-assignment>

<context-root>ssotest</context-root>

</weblogic-web-app>

P.S По поводу пункта 3 и 4...  Настоятельно рекомендуется положить krb5Login.conf и keytab в директорию домена.
Если создавать какуй-то папку для этого дела.. походу надо чётко указывать пути(т.е в ServerStart путь до krb5Login.conf  и в krb5Login.conf путь до keytab файла)
В случае же если они лежат в директории домена keytab будет искаться именно там. Наверное.

P.P.S так тестовую прикладуху можно спизить из этого http://www.oracle.com/technetwork/articles/idm/weblogic-sso-kerberos-1619890.html поста но у меня не получилось заставить её работать из-за проблем с версией java и рекомпилить её было лень.


Не большое дополнение:
Так же при попытке зайти на тестовую прикладуху http://weblogicserver/ssotest вы можете получать ошибку 401 unauthorized хотя всё сделали правильно.

После включение atn debug в weblogic в manageserver.log возможны следующие строки:
<<WLS Kernel>> <> <12f3f237012906ff:-a636d22:14cd70911a2:-8000-0000000000001ef0> <1429615677281> <BEA-000000> <GSSExceptionInfo:> 
####<Apr 21, 2015 2:27:57 PM MSK> <Debug> <SecurityAtn> <myweblogicserver> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <12f3f237012906ff:-a636d22:14cd70911a2:-8000-0000000000001ef0> <1429615677281> <BEA-000000> <   major: (13) : No valid credentials provided> 
####<Apr 21, 2015 2:27:57 PM MSK> <Debug> <SecurityAtn> <myweblogicserver> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <12f3f237012906ff:-a636d22:14cd70911a2:-8000-0000000000001ef0> <1429615677281> <BEA-000000> <   minor: (-1) : Failed to find any Kerberos Key> 
####<Apr 21, 2015 2:27:57 PM MSK> <Debug> <SecurityAtn> <myweblogicserver> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <12f3f237012906ff:-a636d22:14cd70911a2:-8000-0000000000001ef0> <1429615677282> <BEA-000000> <acceptGssInitContextToken failed
com.bea.security.utils.kerberos.KerberosException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)
Caused By: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)

По мимо всего того что предложенно на металинке типа посмотреть файлик /etc/hosts что там всё впоряде и т.д.
Необходимо убедится что username=userPrincipalName !
т.е важно создать правильно keytab:
ktpass -princ HTTP/srv_budwf@WCC.LOCAL -mapuser srv_budwf -kvno 0 -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass lalal_1 -out c:\temp\budwf.keytab


+
Так же  401 unauthorized хотя всё сделали правильно в manageserver.log возможны следующие строки:
####<Jan 22, 2016 11:28:19 AM MSK> <Debug> <SecurityAtn> <budwf.moscow.sportmaster.ru> <budwf_2> <[ACTIVE] ExecuteThread: '26' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <0fb480c4-1579-4383-ba4a-d2a9cb44fe41-00000055> <1453451299311> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000000> <com.bea.common.security.internal.service.JAASIdentityAssertionConfigurationServiceImpl.getAppConfigurationEntry(com.sun.security.jgss.krb5.accept)> 
####<Jan 22, 2016 11:28:19 AM MSK> <Debug> <SecurityAtn> <budwf.moscow.sportmaster.ru> <budwf_2> <[ACTIVE] ExecuteThread: '26' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <0fb480c4-1579-4383-ba4a-d2a9cb44fe41-00000055> <1453451299322> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000000> <Failed to create GSSContext for HTTP/budwf@WCC.LOCAL
GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:87)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:127)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:193)
at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:427)
at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:62)
at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154)
at com.bea.security.utils.kerberos.KerberosTokenUtils.getAcceptGSSContextForService(KerberosTokenUtils.java:293)
at com.bea.security.utils.kerberos.KerberosTokenHandler.handleInitTokenForMultiKDC(KerberosTokenHandler.java:236)
at com.bea.security.utils.kerberos.KerberosTokenHandler.access$100(KerberosTokenHandler.java:46)
at com.bea.security.utils.kerberos.KerberosTokenHandler$2.run(KerberosTokenHandler.java:215)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
at com.bea.security.utils.kerberos.KerberosTokenHandler.acceptGssInitContextToken(KerberosTokenHandler.java:213)
at com.bea.security.utils.kerberos.KerberosTokenHandler.acceptGssInitContextToken(KerberosTokenHandler.java:141)
at com.bea.common.security.internal.utils.negotiate.SPNEGONegotiateToken.getUsername(SPNEGONegotiateToken.java:57)
at weblogic.security.providers.authentication.NegotiateIdentityAsserterProviderImpl.assertChallengeIdentity(NegotiateIdentityAsserterProviderImpl.java:217)
at com.bea.common.security.internal.legacy.service.ChallengeIdentityAssertionProviderImpl$ChallengeIdentityAsserterV2Adapter.assertChallengeIdentity(ChallengeIdentityAssertionProviderImpl.java:124)


Короче данный пиздец присутствует исключительно в weblogic (FMW 12.2.1).
Есть подозрение что как то разъебали negotiate identity assertion provider.
Что делать не понять, хоть пиши кастомный...
Кажется найдено решение читаем коммент от batbear!

Решение 2 скажем так по проще:
Короче суть такова что долбанные индусы переписали свой гавно код и если в fmw 12.1.3 (weblogic) по поводу аналогичной ошибки я писал что "Необходимо убедится что username=userPrincipalName !"
То теперь всё помнялось блять!!
Теперь при генерации keytab
userPrincipalName=Hostname (на который вы генерите keytab) т.е. команда генерации keytab должна выглядеть следющим образом:
ktpass -princ HTTP/budwf@WCC.LOCAL -mapuser srv_budwf -kvno 0 -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass lalal_1 -out c:\temp\budwf.keytab

Если хост к кторому все будут обращться например budwf.lalal.com то keytab надо генерить как:
ktpass -princ HTTP/budwf.lalal.com@WCC.LOCAL -mapuser srv_budwf -kvno 0 -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -pass lalal_1 -out c:\temp\budwf.keytab

В этом случае всё будет работать на 12.2.1, и поидее развалится на 12.1.3
Такая вот хуйня!..

P.S для AES256 незабыть про Java Cryptography Extension (JCE) Unlimited Strength.
P.P.S В тестовой прикладухе ssotest можно получить ошибку 403 forbidden что скорее всего говорит о том что kerberos отработал и проблема уже в авторизации.

Небольшой бонус.
При аутентификации могут проблемы когда она тупо работет медленно. Вся херня в UDP. Подробнее почитать можно тут:
WNA slow Authentication. loss UDP packets