WNA Authentication. Потери UDP пакетов.

Решение проблемы с медленной аутентификацией (у нас доходило до  1 минуты) пользователей, использующих WNA.

Окружение:
Несколько доменом Windows.
Master Keytab для всех доменов.
Очень "большая" сеть.


В логах OAM-сервера WLS_OAM1.out:

KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ
default etypes for default_tkt_enctypes: 17 23.
Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 17 23.
Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 17 23.
default etypes for default_tkt_enctypes: 17 23.
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=uaad1sm.smua.local UDP:88, timeout=30000, number of retries =3, #bytes=236
>>> KDCCommunication: kdc=uaad1sm.smua.local UDP:88, timeout=30000,Attempt =1, #bytes=236
SocketTimeOutException with attempt: 1
>>> KDCCommunication: kdc=uaad1sm.smua.local UDP:88, timeout=30000,Attempt =2, #bytes=236
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=uaad1sm.smua.local UDP:88, timeout=30000,Attempt =3, #bytes=236
SocketTimeOutException with attempt: 3
>>> KrbKdcReq send: error trying uaad1sm.smua.local
java.net.SocketTimeoutException: Receive timed out
        at java.net.PlainDatagramSocketImpl.receive0(Native Method)
        at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:146)
        at java.net.DatagramSocket.receive(DatagramSocket.java:817)
        at sun.security.krb5.internal.UDPClient.receive(NetClient.java:207)
        at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:390)
        at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:343)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.krb5.KdcComm.send(KdcComm.java:327)
        at sun.security.krb5.KdcComm.send(KdcComm.java:219)
        at sun.security.krb5.KdcComm.send(KdcComm.java:191)
        at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:319)
        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:364)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:735)
        at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:584)
        at sun.reflect.GeneratedMethodAccessor1782.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)

Необходимо добавить в конфиг krb5.conf:
[libdefaults]
udp_preference_limit = 1


Что это такое:
udp_preference_limit
When sending a message to the KDC, the library will try using TCP before UDP if the size of the message is above udp_preference_limit. If the message is smaller thanudp_preference_limit, then UDP will be tried before TCP. Regardless of the size, both protocols will be tried if the first attempt fails.

После этого в логах всё ок:
default etypes for default_tkt_enctypes: 17 23.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=uaad1sm.smua.local TCP:88, timeout=30000, number of retries =3, #bytes=153
>>> KDCCommunication: kdc=uaad1sm.smua.local TCP:88, timeout=30000,Attempt =1, #bytes=153
>>>DEBUG: TCPClient reading 177 bytes
>>> KrbKdcReq send: #bytes read=177
>>>Pre-Authentication Data:
         PA-DATA type = 11
         PA-ETYPE-INFO etype = 23, salt =

Weblogic 12.2.1 WNA

После оновления weblogic с 12.1.3 до 12.2.1 внезапно перестала работать Windows Native Authentication.

Конфигурационные файлы при обновлении не менялись. Манипуляций с кейтабами не проводилось. 

Сообщения в логах:

<Debug> <SecurityAtn> <sm-ecm-idm-test1.moscow.sportmaster.ru> <tst_1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <6d5d0986-0aaa-4118-ace1-d9a310c02383-00000021> <1454403844063> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000000> <Failed to create GSSContext for HTTP/sm-ecm-idm-test1.moscow.sportmaster.ru@GKSM.LOCAL
GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:87)

Общение с техподдержкой результатов не дало.

На данный момент найден воркэраунд - перегенерить кейтаб.

Для Weblogic 12.1.3 кейтаб генерировался по следующей схеме.

FQDN: someserver.somedomain

UserName: someserver_srv

UserPrincipalName: HTTP/someserver_srv@ADDOMAIN

SPN: someserver.somedomain

То есть имя сервера обычно не совпадает с именем учётки, которая создаётся для кейтаба.
Кейтаб генерируется безявного указания UserPrincipalName.
После генерации кеутаба добавляется spn, соответствующий FQDN.

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

рабочий воркэраунд:

FQDN: someserver.somedomain

UserName: someserver_srv

UserPrincipalName: HTTP/someserver@ADDOMAIN

То есть при генерации кейтаба надо явно указать UserPrincipalName = hostname.
Если этого не сделать, бесполезно потом добавлять правильные SPN. Работать всё равно не будет.

Embedded Ldap Error (conn=1 op=0 RESULT err=0 tag=0 nentries=0 etime=0)

После одного из внезапных ребутов сервера возникли проблемы со свтроенным LDAP-каталогом сервера Weblogic.
Обнаружилось по всё замедляющейся работе сервера приложений.

Netstat показал, что к серверу wsm-pm открыто более 37 000 соединений.
Netstat -ntp | grep 8003 | wc -l
34872
В логах самого сервера сообщений об ошибках не наблюдалось, но в LDAP-логи
${DOMAIN_HOME}/servers/${servername}/data/ldap/log со скоростью несколько сотен в секунду добавлялись вот такие записи:

[20/Jan/2016 11:43:12 MSK] conn=1 op=0 BIND dn="cn=Admin" method=0 version=3
[20/Jan/2016 11:43:12 MSK] conn=1 op=0 RESULT err=0 tag=0 nentries=0 etime=0

Лечится удалением папки  ${DOMAIN_HOME}/servers/${servername}/data/ldap
и ${DOMAIN_HOME}/servers/${servername}/data/store
Они отреплицируются с AdminServer-а после того, как ManagedServer будет перезапущен.

Unpublished kernel bug 21683388

Сегодня нашёл ноту на металинке с подтверждением важного исправления для многих своих установок. Unpublish kernel bug 21683388.

Баг исправлен в ноябре прошлого года.

Проблема проявлялется в падении ядра при использовании связки

Oracle Linux 6 (kernel 3.8.13-98.6.1) или ниже + HugePages

JVM с ключом -XX:+UseLargePages

В такой конфигурации после нескольких часов работы сервер уходил в ребут с примерно таким сообщением об ошибке:

------------[ cut here ]------------
Jan 19 11:17:33 serverName kernel: WARNING: at lib/list_debug.c:33 __list_add+0xbe/0xd0()
Jan 19 11:17:33 serverName kernel: Hardware name: ProLiant BL460c Gen9
Jan 19 11:17:33 serverName kernel: list_add corruption. prev->next should be next (ffff883f174af828), but was ffff883f209a7e20. (prev=ffff883f218688c0).
Jan 19 11:17:33 serverName kernel: Modules linked in: mptctl mptbase autofs4 cpufreq_ondemand pcc_cpufreq bonding ipv6 scsi_dh_alua sg serio_raw ses enclosure hpilo hpwdt coretemp hwmon freq_table mperf intel_powerclamp kvm ghash_clmulni_intel microcode pcspkr ioatdma dca shpchp ext4 jbd2 mbcache dm_round_robin sd_mod crc_t10dif usb_storage aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul qla2xxx scsi_transport_fc scsi_tgt crc32c_intel be2net be2iscsi bnx2i cnic uio cxgb4i cxgb4 xhci_hcd cxgb3i libcxgbi cxgb3 mdio libiscsi_tcp qla4xxx wmi iscsi_boot_sysfs libiscsi scsi_transport_iscsi dm_multipath dm_mirror dm_region_hash dm_log dm_mod
Jan 19 11:17:33 serverName kernel: Pid: 2888, comm: java Tainted: G        W    3.8.13-68.3.4.el6uek.x86_64 #2
Jan 19 11:17:33 serverName kernel: Call Trace:
Jan 19 11:17:33 serverName kernel: [<ffffffff8105e83f>] warn_slowpath_common+0x7f/0xc0
Jan 19 11:17:33 serverName kernel: [<ffffffff8105e936>] warn_slowpath_fmt+0x46/0x50
Jan 19 11:17:33 serverName kernel: [<ffffffff8129bf7e>] __list_add+0xbe/0xd0
Jan 19 11:17:33 serverName kernel: [<ffffffff81173e8e>] region_chg+0x7e/0x100
Jan 19 11:17:33 serverName kernel: [<ffffffff81173f72>] vma_needs_reservation+0x62/0xb0
Jan 19 11:17:33 serverName kernel: [<ffffffff81174c52>] alloc_huge_page+0x62/0x2c0
Jan 19 11:17:33 serverName kernel: [<ffffffff811308fe>] ? find_get_page+0x1e/0xa0
Jan 19 11:17:33 serverName kernel: [<ffffffff81175390>] hugetlb_no_page+0xa0/0x360
Jan 19 11:17:33 serverName kernel: [<ffffffff81176797>] hugetlb_fault+0x337/0x430
Jan 19 11:17:33 serverName kernel: [<ffffffff8115d9e8>] __handle_mm_fault+0x168/0x1f0
Jan 19 11:17:33 serverName kernel: [<ffffffff81098090>] ? wake_up_state+0x10/0x20
Jan 19 11:17:33 serverName kernel: [<ffffffff8115db22>] handle_mm_fault+0xb2/0x1a0
Jan 19 11:17:33 serverName kernel: [<ffffffff8159ed37>] __do_page_fault+0x217/0x4d0
Jan 19 11:17:33 serverName kernel: [<ffffffff810bf6f0>] ? do_futex+0x100/0x1b0
Jan 19 11:17:33 serverName kernel: [<ffffffff8159968d>] ? __schedule+0x3fd/0x720
Jan 19 11:17:33 serverName kernel: [<ffffffff810bf81b>] ? sys_futex+0x7b/0x180
Jan 19 11:17:33 serverName kernel: [<ffffffff8159effe>] do_page_fault+0xe/0x10
Jan 19 11:17:33 serverName kernel: [<ffffffff8159b498>] page_fault+0x28/0x30
Jan 19 11:17:33 serverName kernel: ---[ end trace 71a6e99ef3a2ba66 ]---

Лечится обновлением ядра.