я к тому, что на тестовую машину с шарой, которая не в домене, ты лезешь с доменной учёткой. надоть на машине с шарой создать такую же учётку, и чтобы она имела доступ к шаре. на домен, насколько помню, в этом
случае ей будет насрать.. но могу ошибаться(для теста можно и отключить).
ну вот сам посуди. smbv1 для самбы сканера поднят. окружение, в виде upnp и сетевого обнаружения(для всех сетей(для теста), с доступом по паролю- этот момент проверяй, так как без работающего upnp опции применяются, но
не работают(сбрасываются обратно)) поднято. лезет именно на эту машину, и порты у неё доступны. учётка существует и имеет разрешение на доступ к шаре. что ещё? там нет ничего больше
Это в теории...
А на практике видим загаду.
Вот здесь описан процесс сеанcа SMB: https://richardkok.wordpress.com/2011/02/03/wireshark-determining-a-smb-and-ntlm-version-in-a-windows-environment/
Так вот, у нас на 1803 пакеты только 1 и 2 шагов. Т.е. Negotiate Request от принтера и Negotiate Response от рабочей станции. Дальше все.
Я сравнивал negotiate response'ы от LTSB(где все хорошо) и от 1803(где плохо). Отличия минимальны.
Вот это в респонсе от LTSB:
Security Blob: 607606062b0601050502a06c306aa03c303a060a2b060104…
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
Simple Protected Negotiation
negTokenInit
mechTypes: 5 items
MechType: 1.3.6.1.4.1.311.2.2.30 (NEGOEX - SPNEGO Extended Negotiation Security Mechanism)
MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
MechType: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
negHints
hintName: not_defined_in_RFC4178@please_ignore
Вот это в респонсе от 1803:
Security Blob: 6082013c06062b0601050502a08201303082012ca01a3018…
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
Simple Protected Negotiation
negTokenInit
mechTypes: 2 items
MechType: 1.3.6.1.4.1.311.2.2.30 (NEGOEX - SPNEGO Extended Negotiation Security Mechanism)
MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
mechToken: 4e45474f4558545301000000000000006000000070000000…
Т.е. в случае LTSB на пример приходит еще инфа, что авторизоваться можно и по Kerberos.
Но далее по пакетам сессии SMB видно, что используется именно NTLMSSP, который в респонсе от 1803 присутствует. Вопщем, загадка.
Но разница в SMB Negotiate Responce от разных сборок Windows 10 все же есть...
SMB в разных сборках Windows 10
