LINUX.ORG.RU

samba+ad не пускает по IP


0

1

Странность такая случилась с утра: При попытке зайти по адресу сервера (\\192.168.0.9) сервер запрашивает авторизацию, ввожу - Отказано в доступе, снова запрос данных.

Если ходить по имени (\\filesrv), все работает.

Проблема в том, что бухи не в домене, и их ни в какую не пускает на сервер, все МФУ разучились складывать сканы в папки, vpn-юзеры не могут подцепиться к серву и т.д.

Если коротко о том, что случилось, так это я менял маску в dhcp с 24 на 23, следовательно и на интерфейсах серверов тоже ее менял. Сейчас, в панике вернул маски на серверах и своем хосте. Результатов ноль.

CentOS 5.9 x86_64 smb.conf (3.5.21)

[global]
netbios name = filesrv
security = ads
server string = filesrv
workgroup = KOMISGROUP
realm = KOMISGROUP.RU
auth methods = winbind
password server = 192.168.0.7
hosts allow = 192.168.
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind separator = \
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = yes
preferred master = No
log file = /var/log/samba/log.%m
log level = 3
panic action = /usr/share/samba/panic-action %d
smb ports = 139
username map = /etc/samba/smbusers
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
display charset = cp1251
unix charset = cp1251
dos charset = cp866
vfs object = recycle

[Privat]
        comment = Privat
        path = /work/privat
        write list = @«%D\work users»
        admin users = @«%D\domain admins»
        read only = no
        create mask = 0660
        directory mask = 0770
        printable = no
        locking = no
Кусок лога (отказ доступа по ip):
[2014/07/07 12:46:40.176745,  3] smbd/sesssetup.c:1254(reply_sesssetup_and_X_spnego)
  NativeOS=[] NativeLanMan=[] PrimaryDomain=[]
[2014/07/07 12:46:40.176787,  3] libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[admin] domain=[KOMISGROUP] workstation=[ADMINISTRATOR] len1=24 len2=274
[2014/07/07 12:46:40.176855,  3] smbd/map_username.c:188(map_username)
  Mapped user admin to root
[2014/07/07 12:46:40.177268,  3] auth/auth.c:216(check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [KOMISGROUP]\[admin]@[ADMINISTRATOR] with the new password interface
[2014/07/07 12:46:40.177309,  3] auth/auth.c:219(check_ntlm_password)
  check_ntlm_password:  mapped user is: [KOMISGROUP]\[root]@[ADMINISTRATOR]
[2014/07/07 12:46:40.177339,  3] smbd/sec_ctx.c:210(push_sec_ctx)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2014/07/07 12:46:40.177360,  3] smbd/uid.c:429(push_conn_ctx)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2014/07/07 12:46:40.177386,  3] smbd/sec_ctx.c:310(set_sec_ctx)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2014/07/07 12:46:40.227522,  3] smbd/sec_ctx.c:418(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2014/07/07 12:46:40.227576,  2] auth/auth.c:314(check_ntlm_password)
  check_ntlm_password:  Authentication for user [admin] -> [root] FAILED with error NT_STATUS_ACCESS_DENIED
[2014/07/07 12:46:40.227612,  3] smbd/error.c:80(error_packet_set)
  error packet at smbd/sesssetup.c(111) cmd=115 (SMBsesssetupX) NT_STATUS_ACCESS_DENIED

Куда посоветуете копать? Меня сожрут скоро.

Ответ на: комментарий от handbrake

до сегодняшнего дня работало с 192.168.

выставил 192.168.0.0/24, то же самое.

mrPresedent
() автор топика

если горит, security=share и разбираться
внутренний домен .ru - однозначное зло, резолвится могут внешники

handbrake ★★★
()
Ответ на: комментарий от handbrake

Людям через сетевое окружение вход делать советуем, так что горячка спала немного. Выставлять share как то страшновато, все завязано на NT авторизации и политиках аудита, дабы знать кто когда что меняет/удаляет/создает.

Сделал smbpasswd -a root, под ним тоже не пускает, даже список шар не выдает.

[2014/07/07 13:37:10.121407,  3] libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[root] domain=[ADMINISTRATOR] workstation=[ADMINISTRATOR] len1=24 len2=274
[2014/07/07 13:37:10.121868,  3] auth/auth.c:216(check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [ADMINISTRATOR]\[root]@[ADMINISTRATOR] with the new password interface
[2014/07/07 13:37:10.121918,  3] auth/auth.c:219(check_ntlm_password)
  check_ntlm_password:  mapped user is: [FILESRV]\[root]@[ADMINISTRATOR]
[2014/07/07 13:37:10.121946,  3] auth/auth_winbind.c:54(check_winbind_security)
  check_winbind_security: Not using winbind, requested domain [FILESRV] was for this SAM.
[2014/07/07 13:37:10.121968,  2] auth/auth.c:314(check_ntlm_password)
  check_ntlm_password:  Authentication for user [root] -> [root] FAILED with error NT_STATUS_NO_SUCH_USER
[2014/07/07 13:37:10.121999,  3] smbd/error.c:80(error_packet_set)
  error packet at smbd/sesssetup.c(111) cmd=115 (SMBsesssetupX) NT_STATUS_LOGON_FAILURE

Пробую через smbclient зайти, получаю следующее (вне зависимости от того, использую ли я ip или имя)

[root@mail ~]# smbclient -L 192.168.0.3 -U KOMISGROUP\\admin
Enter KOMISGROUP\admin's password:
Domain=[KOMISGROUP] OS=[Unix] Server=[Samba 3.6.9-168.el6_5]

        Sharename       Type      Comment
        ---------       ----      -------
        share           Disk
        www             Disk      web platform
        public ftp      Disk      public
        IPC$            IPC       IPC Service (Samba 3.6.9-168.el6_5)
Domain=[KOMISGROUP] OS=[Unix] Server=[Samba 3.6.9-168.el6_5]
-----------
bla bla bla 
-----------

[root@mail ~]# smbclient -L 192.168.0.9 -U KOMISGROUP\\admin
Enter KOMISGROUP\admin's password:
session setup failed: NT_STATUS_ACCESS_DENIED
[root@mail ~]# smbclient -L filesrv -U KOMISGROUP\\admin
Enter KOMISGROUP\admin's password:
session setup failed: NT_STATUS_ACCESS_DENIED

mrPresedent
() автор топика
Ответ на: комментарий от mrPresedent

Не прикручивал никогда в самбе ad - он и от производителя-то глючен и падуч. Так что помогу только от «замыленного глаза» разве что.
Кста - контроллер домена кто ? - если винды, то попробуй на них с клиента зайти может выяснится, что там АД упал - он это любит и умеет.
И у тебя еще passwd server - 0.7 - его проверял ?
и есть у меня большое подозрение что смена маски - это совпадение, возможно что-то давно было поправлено, а тут ты наконец-то конфиги перечитал.
и сеть проверь все тупо по очереди снизу-вверх, я, например, часто пишу 192.198 вместо 192.168 - первый раз замудохался искать, пока не решил по новой адрес прописать... Кста:
логи в самбе емнип позволяют аудит вести без сторонних костылей
rsnapshot + fs с большим количеством инод позволяют спать спокойно.
Если обновлений нигде не было то что-то простое где-то должно быть. Видел неоднократно подобное на secuirty=user, хоть убей вспомнить что это было не могу...

handbrake ★★★
()
Ответ на: комментарий от handbrake

Тоже сильно сомневаюсь что дело в маске. Но это все нормально работало годами, не раз перезагружалось, а сегодня какой то бардак начался. 0.7 - это pdc, он работает, доступен. Выключал его, net ads info показывал переключение на резервный КД (0.8). Дописывал в smb.conf 192.168.0.8 как password server, та же фигня. После ребута контроллера домена, картина не меняется.

mrPresedent
() автор топика
Ответ на: комментарий от mrPresedent

ребут виндов тут явно не причем, он наоборот может картину усложнить - на виндах мог ДНС, например не подняться - кста смотри все службы и не режет ли винда запросы самбы. На сам-то pdc клиенты зайти могут (в тотже netlogon) или если новую какую шару на НЕМ создать ? - может их уже сам pdc не пускает что самба и ретранслирует (смены паролей, например настала), bdc тут показатель, разве только того - жива ли репликация ад и то, это лучше сонаром каким проверять.
Машины одновременно в домен вводились ? Может их учетки поменялись ? Учетка файлопомойки, кстати тоже.
Тут гадать долго можно, я бы со стороны виндов шел. Там, кста секюрити логи смотрел ? Не пропадай плз, отпиши что это было - мне интересно сращивание самбы с виндами, сам к этому присматриваюсь - у меня есть домен-кандидат на миграцию с винды на самбу.

handbrake ★★★
()
Ответ на: комментарий от handbrake

если бы проблема была в dns, он наверное как раз перестал работать с доменными именами, а он почему то при входе по ip не может юзеров подцепить. Учетные данные пользователей не менялись, по крайней мере точно не всех. Мы не работали с pdc уже давно.

Пробую зайти прямо с PDC на 0.9

[2014/07/07 16:04:08.364255,  2] smbd/sesssetup.c:1413(setup_new_vc_session)
  setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources.
[2014/07/07 16:04:08.364275,  3] smbd/sesssetup.c:1212(reply_sesssetup_and_X_spnego)
  Doing spnego session setup
[2014/07/07 16:04:08.364300,  3] smbd/sesssetup.c:1254(reply_sesssetup_and_X_spnego)
  NativeOS=[] NativeLanMan=[] PrimaryDomain=[]
[2014/07/07 16:04:08.364337,  3] libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[admin] domain=[KOMISGROUP] workstation=[PDC] len1=24 len2=274
[2014/07/07 16:04:08.364419,  3] smbd/map_username.c:188(map_username)
  Mapped user admin to root
[2014/07/07 16:04:08.364882,  3] auth/auth.c:216(check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [KOMISGROUP]\[admin]@[PDC] with the new password interface
[2014/07/07 16:04:08.364931,  3] auth/auth.c:219(check_ntlm_password)
  check_ntlm_password:  mapped user is: [KOMISGROUP]\[root]@[PDC]
[2014/07/07 16:04:08.364962,  3] smbd/sec_ctx.c:210(push_sec_ctx)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2014/07/07 16:04:08.364984,  3] smbd/uid.c:429(push_conn_ctx)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2014/07/07 16:04:08.365012,  3] smbd/sec_ctx.c:310(set_sec_ctx)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2014/07/07 16:04:08.411799,  3] smbd/sec_ctx.c:418(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2014/07/07 16:04:08.411839,  2] auth/auth.c:314(check_ntlm_password)
  check_ntlm_password:  Authentication for user [admin] -> [root] FAILED with error NT_STATUS_ACCESS_DENIED
[2014/07/07 16:04:08.411874,  3] smbd/error.c:80(error_packet_set)
  error packet at smbd/sesssetup.c(111) cmd=115 (SMBsesssetupX) NT_STATUS_ACCESS_DENIED

net ads info говорит о том, что сейчас основным KD и LDAP server-ом является 192.168.0.8 (rdc). Иду на него и вижу в журналах следующее при попытке зайти по адресу с него же на файловик:

Запрошен билет проверки подлинности Kerberos(TGT).

Сведения об учетной записи:
	Имя учетной записи:		filesrv$
	Предоставленное имя сферы:	KOMISGROUP.RU
	Идентификатор пользователя:			KOMISGROUP\filesrv$

Сведения о службе:
	Имя службы:		krbtgt
	Код службы:		KOMISGROUP\krbtgt

Сведения о сети:
	Адрес клиента:		192.168.0.9
	Порт клиента:		58540

затем

Запрошен билет службы Kerberos.

Сведения об учетной записи:
	Имя учетной записи:		FILESRV$@KOMISGROUP.RU
	Домен учетной записи:		KOMISGROUP.RU
	GUID входа:		{7e2d4661-8c9f-9fbb-a6d0-b2acedce1c75}

Сведения о службе:
	Имя службы:		RDC$
	Идентификатор службы:		KOMISGROUP\RDC$

Сведения о сети:
	Адрес клиента:		192.168.0.9
	Порт клиента:		49557
Далее аналогично:
Запрошен билет службы Kerberos.

Сведения об учетной записи:
	Имя учетной записи:		FILESRV$@KOMISGROUP.RU
	Домен учетной записи:		KOMISGROUP.RU
	GUID входа:		{7e2d4661-8c9f-9fbb-a6d0-b2acedce1c75}

Сведения о службе:
	Имя службы:		krbtgt
	Идентификатор службы:		KOMISGROUP\krbtgt

Сведения о сети:
	Адрес клиента:		192.168.0.9
	Порт клиента:		54688

Вошли
Вход с учетной записью выполнен успешно.

Субъект:
	ИД безопасности:		NULL SID
	Имя учетной записи:		-
	Домен учетной записи:		-
	Код входа:		0x0

Тип входа:			3

Новый вход:
	ИД безопасности:		KOMISGROUP\filesrv$
	Имя учетной записи:		FILESRV$
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x276bdf
	GUID входа:		{45cfd6fd-2d1b-970c-5d17-e6aa3a26b303}
И тут же вышли
Выполнен выход учетной записи из системы.

Субъект:
	ИД безопасности:		KOMISGROUP\filesrv$
	Имя учетной записи:		filesrv$
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x276bdf

Тип входа:			3

Справедливости ради скажу, что конфиги на всех серверах почти одинаковые, и на других все работает как надо. Например, я указывал выше пример входа через smbclient на 192.168.0.3.

mrPresedent
() автор топика
Ответ на: комментарий от handbrake

Фильтр записей по пользователю KOMISGROUP\admin вообще ничего не возвращает. По руту искать - нет такого пользователя. Вообще ни по одному пользователю фильтр не отрабатывает, «давно венды не видел»)

mrPresedent
() автор топика
Ответ на: комментарий от mrPresedent

Фильтр не всегда работает, надо ручками по времени события разгребать, когда народа нет.
Да и откуда пользователь в нем будет, если он аутентификацию, судя по всему, не проходит.
Тоже ад давно не видел, но намудохался с ним знатно. У вас там подстановка root/admin идет, я бы обоих прописал и пароль по новой задал и на лине тоже.

handbrake ★★★
()
Ответ на: комментарий от mrPresedent

Извиняюсь, попробовал штатный ctrl+f, имеем такие события:

Выполнен выход учетной записи из системы.

Субъект:
	ИД безопасности:		система
	Имя учетной записи:		RDC$
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x2cfe02

Тип входа:			3
Затем
Новому сеансу входа назначены специальные привилегии.

Субъект:
	ИД безопасности:		KOMISGROUP\admin
	Имя учетной записи:		admin
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x2cfe36

Привилегии:		SeSecurityPrivilege
			SeBackupPrivilege
			SeRestorePrivilege
			SeTakeOwnershipPrivilege
			SeDebugPrivilege
			SeSystemEnvironmentPrivilege
			SeLoadDriverPrivilege
			SeImpersonatePrivilege
			SeEnableDelegationPrivilege
-----------------------------------------
Вход с учетной записью выполнен успешно.

Субъект:
	ИД безопасности:		NULL SID
	Имя учетной записи:		-
	Домен учетной записи:		-
	Код входа:		0x0

Тип входа:			3

Новый вход:
	ИД безопасности:		KOMISGROUP\admin
	Имя учетной записи:		admin
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x2cfe36
	GUID входа:		{304b52e2-3a90-2efb-6097-be71aebad7ec}

Сведения о процессе:
	Идентификатор процесса:		0x0
	Имя процесса:		-

Сведения о сети:
	Имя рабочей станции:	
	Сетевой адрес источника:	192.168.0.22
	Порт источника:		52668

Сведения о проверке подлинности:
	Процесс входа:		Kerberos
	Пакет проверки подлинности:	Kerberos
	Промежуточные службы:	-
	Имя пакета (только NTLM):	-
	Длина ключа:		0
-----------------------------------------
Запрошен билет проверки подлинности Kerberos(TGT).

Сведения об учетной записи:
	Имя учетной записи:		filesrv$
	Предоставленное имя сферы:	KOMISGROUP.RU
	Идентификатор пользователя:			KOMISGROUP\filesrv$

Сведения о службе:
	Имя службы:		krbtgt
	Код службы:		KOMISGROUP\krbtgt

Сведения о сети:
	Адрес клиента:		192.168.0.9
	Порт клиента:		34840
--------------------------------------------------------
Запрошен билет службы Kerberos.

Сведения об учетной записи:
	Имя учетной записи:		FILESRV$@KOMISGROUP.RU
	Домен учетной записи:		KOMISGROUP.RU
	GUID входа:		{0d1dce3b-7572-0a3c-1c45-6928e48e3ca4}

Сведения о службе:
	Имя службы:		RDC$ и krbtgt
	Идентификатор службы:		KOMISGROUP\RDC$ и krbtgt

Сведения о сети:
	Адрес клиента:		192.168.0.9
	Порт клиента:		48555

Якабы зашли
Вход с учетной записью выполнен успешно.

Субъект:
	ИД безопасности:		NULL SID
	Имя учетной записи:		-
	Домен учетной записи:		-
	Код входа:		0x0

Тип входа:			3

Новый вход:
	ИД безопасности:		KOMISGROUP\filesrv$
	Имя учетной записи:		FILESRV$
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x2cfeab
	GUID входа:		{95ba7a9d-6938-8e37-f592-d0e98567eb7b}

Сведения о процессе:
	Идентификатор процесса:		0x0
	Имя процесса:		-

Сведения о сети:
	Имя рабочей станции:	
	Сетевой адрес источника:	192.168.0.9
	Порт источника:		57848

Выполнен выход учетной записи из системы.

Субъект:
	ИД безопасности:		KOMISGROUP\admin
	Имя учетной записи:		admin
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x2cfe36

Тип входа:			3

иииииииииии

Выполнен выход учетной записи из системы.

Субъект:
	ИД безопасности:		KOMISGROUP\filesrv$
	Имя учетной записи:		filesrv$
	Домен учетной записи:		KOMISGROUP
	Код входа:		0x2cfeab

Тип входа:			3

mrPresedent
() автор топика
Ответ на: комментарий от handbrake

Входит админ, входит filesrv, выходит admin, выходит filesrv. Строго по порядку копипаст журнала безопасности.

Реально ни на одном другом сервере таких бед нет. Видимо CentOS 5.9 придется обновлять так или иначе в скором, и самбу заодно. Хотя с нее бы и начать. Если идей к вечеру не появится больше, буду yum install samba )

mrPresedent
() автор топика
Ответ на: комментарий от mrPresedent

это еще не показатель, винды могут говорить ok и не пускать, там надо рядом все записи разгребать
Обновляли - что-нибудь перед инцидентом ?

handbrake ★★★
()
Ответ на: комментарий от handbrake

Нет, только расширение сети через маску было в планах. Больше никто ничего не трогал. Сейчас копаюсь в других серверах. Ими никто не пользуется, кроме нас. У них разные KDC сейчас по версии net ads info. И на сервере с контроллером 0.7 не работает вход через hostname, но работает по ip. Соответственно аналогичная картина, но наоборот.

mrPresedent
() автор топика
Ответ на: комментарий от handbrake

ммм, какие слова интересные) DNS на обоих, контроллеры смотрят друг на друга вторичными днс. На клиентах dhcp дает днс обоих КД, на серверах аналогично. Поднимая вторичный КД ничего с днс не делал, так что вероятно нету.

mrPresedent
() автор топика
Ответ на: комментарий от handbrake

вот зацепочка, положил rdc, серв переключился на pdc, потерял группы. wbinfo -u еще отрабатывает, но getent passwd и group уже молчат.

Ну что ж, net ads leave && net ads join. Вошел, но с DNS update failed.

Зато....теперь эта *?:%;?*!@# работает! Ходит и по имени, и по адресу...

Мда, вендокапецный косяк с потерянным доверием или еще черт знает что может быть. На старой работе PDC делал на Debian+samba4, так он и на не-stable версии работал без косяков, ни одного выпавшего хоста, «отсутствуют серверы, что бы выполнить запрос» и т.д. за полгода. Жаль, не изучил я тогда все его возможности относительно групповых политик, т.к. сейчас у нас через них куда проще этой оравой мозгоедов управлять. Помню, как пришел на эту работу, pdc на ладан дышал, а резервный контроллер просто мертвым валялся, так что проще было новый поднять.

mrPresedent
() автор топика
Ответ на: комментарий от mrPresedent

Я не спроста тут в одной теме признался, что отказался от АД в пользу рабочей группы+набора самописных батников-костылей, выполняющих 90% его функционала.
Но вопрос у тебя не решен, в любой момент может что-то отвалится, здоровье АД - вещь очень хрупкая. У тебя не проблемы доверия. И радуйся, что не вляпался в GP, представь что может случится, если у тебя настройки и софт начнут расползаться игнорируя условия целей.

handbrake ★★★
()
Ответ на: комментарий от handbrake

Больше всего мой начальник боялся и боится смерти домена. У них год назад старый домен хоронили, до сих пор бухи сидят в нем, т.к. банков свыше 20, в т.ч. забугорные без русскоязычной техподдержки, добровольцев-самоубийц нет.

Я взялся за полное резервирование этого инфраструктурного добра. Поднять второй КД то не сложно, но до сих пор при падении pdc squid перестает пускать людей, файловик запрашивает авторизацию. Одним словом: «Пилите, Шура, пилите». Надо основательно садиться за изучение pam и ntlm, т.к. при всем желании, от MS далеко не уйти.

mrPresedent
() автор топика
Ответ на: комментарий от mrPresedent

сквид с ntlm - не жилец, пробовал, сначала живет, потом чилдренов ему подавай в геометрической прогрессии, потом ничего не помогает.
bdc - временная мера, которая может сделать хуже. Да оно как-бы помогает, можно потом seize сделать и все будет в порядке, по логам, по работе по всему. ЯКОБЫ. Изучать АД бессмысленно - я порушенные леса восстанавливал закрытыми патчами и правкой баз в hiew. Этот монстр мертв по рождению. DNS может давать сбои в самых непредсказуемых местах, dhcp с ddns может прямо и/или обратно не резолвиться, показывая все нормально во всех оснастках и через раз реагировать на сбросы кэшей. Практически всегда лечение дает временный эффект. Репликация может как развалиться, так и самопочиниться спустя год, несмотря на состояние давно переполненного журнала или поврежденного журнала.
Я перечитал по АД документации больше чем хотел - его невозможно понять. Он как зона в «пикнике на обочине», если ты считаешь, что понял АД - он родит совершенно неописуемую аномалию.

handbrake ★★★
()
Ответ на: комментарий от mrPresedent

От мс можно уйти если задаться целью и все продумать. Но будет поначалу больно и непривычно. Но зато работать будет потом предсказуемо и стабильно.

no-dashi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.