Падключэнне сеткавага дыска VPN з уліковым запісам Samba, які ведае сервер

Падключыце тунэль, а агульны рэсурс па-ранейшаму запытвае пароль, які карыстальнік лічыць правільным. У аўтаномным разгортванні Samba ўваход VPN і ўваход SMB — незвязаныя ўліковыя даныя: адзін аўтарызуе тунэль, другі правярае файлавы сервер. Таму падключэнне дыска з уліковым запісам VPN не ўдаецца, нават калі пароль правільны і сеткавы шлях бездакорны. Гэтая розніца тлумачыць большасць збояў падключэння праз VPN.

Рашэнне не ў скідзе ўліковага запісу VPN. Трэба назваць ідэнтычнасць, якую сервер Samba сапраўды ведае, а потым праверыць, ці мае гэтая ж ідэнтычнасць правы на рэсурс і каталог.

Уваход VPN і ўваход SMB — розныя ідэнтычнасці

Уліковы запіс VPN ацэньвае VPN-шлюз паводле ўласнай палітыкі. Ён адказвае, ці можа гэты кліент увайсці ў прыватную сетку. Ён нічога не кажа пра тое, які ўліковы запіс SMB існуе на файлавым серверы ў гэтай сетцы.

Уліковы запіс Samba жыве ў сервернай частцы аўтэнтыфікацыі, са сваёй базай пароляў і сваім імем. Дзве машыны могуць абедзве мець карыстальніка з імем alice, не падзяляючы сістэму ідэнтычнасці, пароль ці ідэнтыфікатар карыстальніка. Імёны супадаюць; уліковыя запісы — не.

Сервер Samba, інтэграваны ў дамен, змяняе карціну: ідэнтычнасць паходзіць з каталога і Kerberos, а не з лакальнага спісу ўліковых запісаў. У гэтым выпадку выкарыстоўвайце ідэнтычнасць з каталога і падтрымліваемую канфігурацыю SMB, а не стварайце лакальныя дублікаты, імітуючы членства ў дамене. Праверце, якую мадэль выкарыстоўвае сервер, перш чым ствараць уліковы запіс.

Паглядзіце, якую ідэнтычнасць Windows выкарыстоўвае насамрэч

Windows кэшуе падключэнні для кожнага сервера. Калі існуючы сеанс да таго ж сервера быў адкрыты пад іншым уліковым запісам, новае падключэнне можа паўторна выкарыстаць гэты сеанс або скончыцца памылкай аўтэнтыфікацыі з указаннем няправільнага карыстальніка. Так правільны пароль выглядае няправільным. Прагледзьце бягучыя падключэнні, перш чым змяняць уліковыя даныя.

net use
cmdkey /list
klist

Першая каманда паказвае падключаныя дыскі і адкрытыя сеансы, другая — захаваныя ўліковыя даныя, якія могуць ужывацца аўтаматычна, а трэцяя — квіткі Kerberos, калі выкарыстоўваецца дамен. Захаваныя ўліковыя даныя могуць моўчкі перавызначыць уліковы запіс, які вы збіраліся ўвесці.

Выдаліце толькі тое падключэнне або тыя ўліковыя даныя, што датычаць гэтай праблемы. Адключэнне ўсіх дыскаў або замена імені сервера IP-адрасам хавае выбар ідэнтычнасці і можа парушыць подпіс або палітыкі на аснове імёнаў.

Падключыце рэсурс з уліковым запісам, які распазнае сервер

Укажыце ўліковы запіс у форме, якую чакае сервер, і дазвольце Windows запытаць пароль, каб сакрэт не трапіў у гісторыю каманд ці скрыпт:

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

Кампанент сервера перад адваротнай касой рыскай — гэта кантэкст ідэнтычнасці сервера Samba, а не VPN-шлюз. Зорачка запытвае інтэрактыўны ўвод пароля, а /persistent:no не дае падключэнню трапіць у наступны ўваход. Выберыце вольную літару дыска.

Калі сервер інтэграваны ў дамен, кампанентам карыстальніка можа быць замест гэтага імя каталога або ідэнтычнасць з даменным прэфіксам. Выкарыстоўвайце форму, задокументаваную адміністратарам; выдумванне лакальнага ўліковага запісу з тым жа імем стварае другую ідэнтычнасць і другі пароль для абслугоўвання.

Сапраўднасць уліковага запісу, доступ да рэсурсу і правы файлавай сістэмы — тры праверкі

Samba правярае, ці праходзіць ідэнтычнасць аўтэнтыфікацыю, ці дапускае яе вызначэнне рэсурсу і ці дае файлавая сістэма запытаную аперацыю. Праходжанне першай праверкі не азначае праходжання дзвюх іншых. Рэсурс можа быць бачным і ўсё роўна адмаўляць у запісе, бо так кажуць правы каталога.

Рэсурс, абмежаваны з дапамогай valid users, дапускае толькі пералічаныя ўліковыя запісы або групы. Уліковы запіс можа правільна прайсці аўтэнтыфікацыю і ўсё роўна быць адхіленым гэтым радком. Праверце вызначэнне рэсурсу, перш чым рабіць выснову, што пароль няправільны.

На баку файлавай сістэмы важныя і працэс Samba, і падключаная ідэнтычнасць. Каталог, што належыць root з рэжымам 700, не прыме запісаў ад звычайнага ўліковага запісу, нават калі вызначэнне рэсурсу гэта дазваляе. Праверце чытаннем, а потым запісам у каталозе, які ўліковы запіс павінен выкарыстоўваць.

Усуньце канфліктны сеанс, не парушаючы палітыку

Калі прычына — састарэлы сеанс, зачыніце менавіта гэта падключэнне і падключыцеся зноў з патрэбным уліковым запісам. Калі захаваныя ўліковыя даныя працягваюць вяртацца, выдаліце іх, а не ўвесь спіс дыскаў. Потым пацвердзіце новы сеанс з дапамогай net use.

Захоўвайце абавязковы подпіс SMB, шыфраванне і палітыку ўліковых запісаў. Сервер, які адхіляе сеанс без подпісу або шыфравання, праводзіць палітыку, а не чытае пароль няправільна, і аслабленне яе дзеля паспяховага падключэння мяняе бяспеку на сімптом.

Запішыце імя сервера, дакладную форму ўліковага запісу і правы на рэсурс і каталог, якія спрацавалі. Інакш наступны чалавек, што падключае дыск, спачатку паспрабуе ўваход VPN, бо менавіта з гэтымі данымі ён трапіў у сетку.