Ошибка входа пользователя usr1cv8

Заделываем дыры в сервере приложений 1С и вокруг него

В сегодняшней статье я расскажу об уязвимостях сервера 1С в корпоративной сети.

Как показала практика, в инсталляциях с 1С все допускают одни и те же ошибки разной степени серьезности. Я не буду касаться очевидных вещей вроде установки обновлений, но пройдусь по специфике работы сервера приложений под Windows. Например, по возможности бесконтрольно манипулировать базами Microsoft SQL с помощью инструментов 1С.

Исторически так сложилось, что редко когда системные администраторы и программисты 1С работают как одна команда. Чаще всего специалисты по 1С не вникают в тонкости системного администрирования, а сисадмины не стремятся постичь нюансы работы 1С.

И получается инфраструктура с «детскими болячками», очевидными для специалиста по ИБ ― ниже привожу личный ТОП таких проблем.

Запускаем сервер правильно

По умолчанию платформа 1С при установке создает специальную учетную запись с ограниченными правами, под которой работают службы сервера ― USR1CV8. Все идет хорошо, до тех пор пока не становятся нужны ресурсы сети: например, для автоматических выгрузок-загрузок. Учетная запись по умолчанию не имеет доступа на сетевые папки домена, поскольку является локальной.

В своей практике я встречал множество способов решения этой задачи: папки с доступом на запись для группы «Все», сервер 1С под учетной записью с правами администратора домена, явно прописанные в коде учетные данные для подключения сетевого ресурса. Даже запуск сервера 1С под пользовательской сессией как обычное приложение.

Заходим на сервер по RDP, видим такое окно и получаем нервный тик.

Конечно, «захардкоженые» пароли и сетевые ресурсы с анонимным доступом на запись встречаются редко. В отличие от работы сервера 1С из-под обычной доменной учетной записи. Разумеется, с возможностью выполнить произвольный код «на сервере».

Как известно любому 1С-нику, но не любому системному администратору, в обработках 1С есть два режима выполнения процедур: на сервере и на клиенте. Запущенная в «серверном» режиме процедура будет выполнена под учетной записью службы сервера приложений. Со всеми ее правами.

Если сервер 1С работает с правами администратора домена, то потенциальный вредитель сможет сделать с доменом что угодно. Разумным выходом станет создание специальной учетной записи ― по мотивам USR1CV8, только уже в домене. В частности, ей стоит разрешить вход только на определенные серверы в оснастке «Пользователи и Компьютеры Active Directory».

Настройка входа только на разрешенные серверы.

Не лишним будет и разрешить вход на сервер только в качестве службы, отключив возможность локального (интерактивного) входа в систему. Сделать это можно через локальные политики безопасности непосредственно на сервере, либо с помощью доменных групповых политик.

Назначение прав пользователя в локальной политике безопасности.

Все то же самое касается и учетной записи сервера Microsoft SQL. Седых волос может прибавиться от вредных привычек:

• запускать SQL с правами администратора компьютера или даже домена для удобного резервного копирования;
• включать возможность запуска исполняемых команд через хранимую процедуру xp_cmdshell для переноса резервных копий на сетевые ресурсы через красивые планы обслуживания.

Подключаемся к SQL

Регулярно в практике встречается подключение баз данных к серверу 1С под пользователем «SA» (суперпользователь в SQL). Вообще, это не так страшно как звучит, ведь пароль от SA захэширован в файле 1CV8Reg.lst на сервере приложений. Хэш злоумышленник получить гипотетически может ― не забываем про права учетной записи сервера ― но расшифровка окажется долгой, особенно если использовать брутфорс.

Но все же не лишним будет настроить аудит доступа к этому файлу с уведомлением ответственных лиц.

Другое дело, когда программистам 1С «делегируют» обязанности DBA. Опять же, из личного опыта: сервер SQL был в зоне ответственности программистов, как и интеграция внешнего сайта с базами 1С. Итогом был пароль SA в скриптах сайта.

Для собственного успокоения стоит поставить на SA сложный пароль или вовсе деактивировать эту учетную запись. На SQL тогда нужно включить доменную аутентификацию для управления и создать для 1С отдельное имя входа с правами на необходимые базы.

Если вы не хотите оставить возможность создавать базы SQL через интерфейс 1С, то новому пользователю хватит общей роли public и db_owner непосредственно в базе 1С.

Это можно проделать через Management Studio или простым скриптом T-SQL:

Пользователи 1С

Правам пользователей в 1С почему-то мало кто уделяет внимание. А ведь пользователь с правами «Административные функции» или «Администрирование» запросто выгрузит базу в .DT через конфигуратор и унесет домой ― это подарит не одно мгновение волнительного счастья вашему руководству. Поэтому стоит поймать на рюмочку чая 1С-ника и посидеть совместно над базой, чтобы узнать, какие пользователи имеют подобные права. А заодно ― чем грозит понижение их полномочий.

Право выгрузить базу у роли Полные Права в типовой 1С: Бухгалтерии 2.0.

Следующий важный момент ― запуск внешних обработок. Как мы помним, в 1С можно запускать код с правами учетной записи сервера. Хорошо, если она не имеет административных прав на систему, но все равно стоит исключить возможность запуска подобных обработок для пользователей. И не забудьте попросить специалиста по 1С «встраивать» дополнительные отчеты и обработки в базу. Хотя не во всех обработках поддерживается встраивание ― эта возможность зависит от версии 1С.

Проверить, какие типовые роли не имеют прав на открытие внешних обработок, можно в конфигураторе.

Все эти действия не только помогут защититься от потенциального «внутреннего вредителя», но и станут дополнительной преградой на пути вирусов-шифровальщиков, маскирующихся под обработки 1С.

Если все же необходим запуск внешних обработок, то неплохим вариантом контроля и подстраховки будет аудит их запуска. Штатного механизма аудита у 1С пока нет, но в сообществе уже придумали несколько обходных маневров. Внедрять эти механизмы стоит в паре со специалистом 1С, также как и настраивать уведомления о событиях в журнале регистраций базы.

Отдельно отмечу возможность настройки доменной аутентификации пользователей вместо аутентификации 1С. И пользователям будет удобнее ― меньше паролей в их памяти снижает риск появления стикеров на мониторе.

Администратор кластера

Итак, пользователи теперь не могут запускать обработки, учетная запись сервера максимально ограничена. Но есть и еще кое-что: учетная запись администратора кластера 1С, которая не создается по умолчанию.

Ее отсутствие опасно: любой человек с ноутбуком при открытом доступе к сетевым портам сервера (по умолчанию это TCP:1540) может создать там свою базу, и ограничений на запуск обработок не будет. А еще злодей сможет получить информацию по базам данных, по работающим пользователям, изменить параметры кластера и даже принудительно завершить работу определенных пользователей.

Пример скрипта на PowerShell, изгоняющего всех пользователей изо всех баз сервера:

Использование подобного способа работы с сервером 1С в благих целях уже упоминалось в одной из предыдущих статей.

Создать администратора кластера не просто, а очень просто ― достаточно щелкнуть правой кнопкой на пункте «администраторы» в управлении кластером 1С, создать нового администратора, задав логин и пароль.

Создание администратора кластера 1С.

Я коснулся лишь части недоработок при настройке 1С: Предприятия. Для самостоятельного изучения рекомендую почитать до сих пор не потерявшие актуальность материалы:

Поделитесь в комментариях своими нестандартными решениями и курьезами при работе с системой 1С: Предприятие.

Источник

MSSQLSERVER_18456

Область применения: SQL Server (все поддерживаемые версии)

Сведения

attribute	Значение
Название продукта	SQL Server
Идентификатор события	18456
Источник события	MSSQLSERVER
Компонент	SQLEngine
Символическое имя	LOGON_FAILED
Текст сообщения	Ошибка имени входа пользователя ‘%.*ls’.%.*ls

Описание

Это сообщение об ошибке появляется при отклонении попытки подключения из-за сбоя проверки подлинности. Вход пользователей может завершиться ошибкой по многим причинам, таким как недопустимые учетные данные, срок действия пароля и включение неправильного режима проверки подлинности. Во многих случаях коды ошибок включают описания.

Рекомендуемые действия

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

Ошибка входа для пользователя » » или ошибка входа для пользователя » «

Если доменное имя не указано, проблема заключается в сбое попытки входа SQL Server. Если указано доменное имя, проблема заключается в сбое входа в учетную запись пользователя Windows. Сведения о потенциальных причинах и предлагаемых решениях см. в разделе:

Возможная причина	Предлагаемое решение
Вы пытаетесь использовать проверку подлинности SQL Server, но для экземпляра SQL Server настроен режим проверки подлинности Windows.	Убедитесь, что SQL Server настроен для использования SQL Server и режима проверки подлинности Windows. Вы можете просмотреть и изменить режим проверки подлинности для экземпляра SQL Server на странице Безопасность в разделе Свойства соответствующего экземпляра в SQL Server Management Studio (SSMS). Дополнительные сведения см. в разделе Изменение режима проверки подлинности сервера. Кроме того, можно изменить приложение, чтобы использовать режим проверки подлинности Windows для подключения к SQL Server. Примечание. Для этого сценария в журнале ошибок SQL Server отображается следующее сообщение: Login failed for user ‘ ‘. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only.
Имя входа не существует в экземпляре SQL Server, к которому вы пытаетесь подключиться.	Убедитесь, что имя входа SQL Server существует и что вы правильно написали его. Если имя входа не существует, создайте его. Если она присутствует, но написана с ошибкой, исправьте это в строке подключения приложения. Журнал ошибок SQL Server будет содержать одно из следующих сообщений: — Login failed for user ‘username’. Reason: Could not find a login matching the name provided. — Login failed for user ‘Domainusername’. Reason: Could not find a login matching the name provided. Это может быть распространенной проблемой, если вы развертываете приложение, использующее сервер DEV или QA, в рабочей среде и не можете обновить строку подключения. Чтобы устранить эту проблему, убедитесь, что вы подключаетесь к соответствующему серверу. В противном случае исправьте строку подключения. Если это так, предоставьте для входа доступ к SQL Server. Или, если это имя входа Windows, предоставьте доступ напрямую или добавьте его в локальную или доменную группу, которая может подключаться к серверу базы данных. Дополнительные сведения см. в разделе Создание имени входа.
Вы используете проверку подлинности SQL Server, но пароль, указанный для входа SQL Server, неверный.	Чтобы подтвердить причину, проверьте журнал ошибок SQL на наличие таких сообщений, как «Причина: пароль не совпадал с данным для имени входа«. Чтобы устранить эту проблему, используйте правильный пароль в приложении или другую учетную запись, если вы не можете запомнить пароль. Кроме того, обратитесь к администратору SQL Server, чтобы сбросить пароль для учетной записи. Если приложение SQL Server службы Integration Services (SSIS), для задания может быть несколько уровней файла конфигурации, что может переопределить параметры диспетчер подключений для пакета. Если приложение было создано вашей компанией и строка подключения создается программным способом, обратитесь к команде разработчиков, чтобы устранить проблему. В качестве временного решения жестко закодируйте строку подключения и проверьте ее. Используйте UDL-файл или скрипт, чтобы подтвердить возможность подключения с помощью жестко заданной строки подключения.
Неправильное имя сервера.	Убедитесь, что вы подключаетесь к правильному серверу.
Вы пытаетесь подключиться с помощью проверка подлинности Windows но вошли в неправильный домен.	Убедитесь, что вы правильно вошли в правильный домен. В сообщении об ошибке обычно отображается доменное имя.
Вы не запускаете приложение (например, SSMS) от имени администратора.	Если вы пытаетесь подключиться с помощью учетных данных администратора, запустите приложение с помощью параметра Запуск от имени администратора . После подключения добавьте пользователя Windows в качестве отдельного имени входа.
Имя входа удаляется после миграции на пользователя автономной базы данных.	Если ядро СУБД поддерживает автономные базы данных, убедитесь, что имя входа не было удалено после миграции на пользователя автономной базы данных. Дополнительные сведения см. в разделе Проверка подлинности автономной базы данных: введение.
База данных входа по умолчанию находится в автономном режиме или недоступна иным образом.	Обратитесь к администратору SQL Server и устраните проблемы, связанные с доступностью базы данных. Если имя входа имеет разрешения на доступ к другим базам данных на сервере и вам не требуется доступ к текущей базе данных по умолчанию в приложении, используйте один из следующих вариантов: — Попросите администратора изменить базу данных по умолчанию для входа с помощью инструкции ALTER LOGIN или SSMS. — явно укажите другую базу данных в строке подключения приложения. Или если вы используете SSMS, перейдите на вкладку Свойства подключения , чтобы указать базу данных, доступную в данный момент.Такие приложения, как SSMS, могут отображать сообщение об ошибке следующего вида: Cannot open user default database. Login failed. Login failed for user . (Microsoft SQL Server, Error: 4064) SQL Server errorlog будет содержать следующее сообщение об ошибке: Login failed for user ‘ ‘. Reason: Failed to open the database ‘ ‘ specified in the login properties [CLIENT: ] Дополнительные сведения см. в разделе MSSQLSERVER_4064.
База данных, явно указанная в строке подключения или в SSMS, неправильно написана, отключена или недоступна иным образом.	— Исправление имени базы данных в строке подключения. — Если имя базы данных верно, обратитесь к администратору SQL Server и устраните проблемы, связанные с доступностью базы данных. Проверьте, находится ли база данных в автономном режиме, не восстановлена и т. д. — Если имя входа сопоставлено с пользователями с разрешениями на другие базы данных на сервере и вам не требуется доступ к текущей настроенной базе данных в приложении, укажите другую базу данных в строке подключения. Если вы подключаетесь с помощью SSMS, используйте вкладку Свойства подключения , чтобы указать базу данных, доступную в данный момент. SQL Server errorlog будет содержать следующее сообщение об ошибке: Login failed for user . Reason: Failed to open the explicitly specified database ‘dbname’. [CLIENT: ] Примечание. Если база данных входа по умолчанию доступна, SQL Server позволяет установить подключение. Дополнительные сведения см. в разделе MSSQLSERVER_4064.
У пользователя нет разрешений на доступ к запрашиваемой базе данных.	— Попробуйте подключиться от имени другого пользователя с правами sysadmin, чтобы узнать, можно ли установить подключение. — предоставьте для входа доступ к базе данных, создав соответствующего пользователя (например, CREATE USER [ ] FOR LOGIN [UserName] ).

Кроме того, ознакомьтесь с обширным списком кодов ошибок на странице Устранение ошибки 18456.

Дополнительные сведения об устранении неполадок см. в статье Устранение неполадок с подключением клиента ИЛИ сервера SQL.

Существует по крайней мере четыре сценария для этой проблемы. В следующей таблице изучите каждую применимую потенциальную причину и используйте соответствующее решение. В примечании под таблицей приведено объяснение термина двойной прыжок.

Возможная причина	Предлагаемые решения
Вы пытаетесь передать учетные данные NT LAN Manager (NTLM) из одной службы в другую службу на том же компьютере (например, из IIS на СЕРВЕР SQL Server), но в процессе возникает сбой.	Добавьте записи реестра DisableLoopbackCheck или BackConnectionHostNames .
Существуют сценарии двойного прыжка (делегирование ограничений) на нескольких компьютерах. Эта ошибка может возникнуть, если подключение Kerberos завершается сбоем из-за проблем с именами субъектов-служб (SPN).	Запустите SQLCheck на каждом SQL Server и веб-сервере. Воспользуйтесь руководствами по устранению неполадок: проблема с делегированием учетных данных 0600 и 0650 SQL Server проблемы с делегированием связанного сервера.
Если двойной прыжок (делегирование ограничений) не используется, скорее всего, существуют дублирующиеся имена субъектов-служб, и клиент работает от имени LocalSystem или другой учетной записи компьютера, которая получает учетные данные NTLM вместо учетных данных Kerberos.	Используйте SQLCheck или Setspn.exe для диагностики и устранения проблем, связанных с spN. Также ознакомьтесь с обзором Configuration Manager Kerberos для SQL Server.
Возможно, настроена политика локальной безопасности Windows, чтобы запретить использование учетной записи компьютера для запросов удаленной проверки подлинности.	Перейдите к локальной политике> безопасностиЛокальные политики>Параметры> безопасностиБезопасность сети: разрешить локальной системе использовать удостоверение компьютера для NTLM, выберите параметр Включено, если параметр отключен, а затем нажмите кнопку ОК. Примечание. Как описано на вкладке Объяснение , эта политика включена в Windows 7 и более поздних версиях по умолчанию.
Краткое возникновение этой проблемы при использовании ограниченного делегирования может указывать на наличие просроченного билета, который не может быть продлен на среднем уровне. Это ожидаемое поведение в сценарии связанного сервера или в любом приложении, которое удерживает сеанс входа более 10 часов.	Измените параметры делегирования на сервере среднего уровня с «Доверять этому компьютеру для делегирования только для указанных служб» — используйте только Kerberos, чтобы доверять этому компьютеру делегирование только указанным службам . Используйте любой протокол. Дополнительные сведения см. в статье Периодический анонимный вход SQL Server двойного прыжка связанного сервера.

Двойной прыжок обычно включает делегирование учетных данных пользователя на нескольких удаленных компьютерах. Например, предположим, что у вас есть экземпляр SQL Server с именем SQL1, на котором вы создали связанный сервер для удаленного SQL Server с именем SQL2. В конфигурации безопасности связанного сервера вы выбрали параметр Быть сделано с использованием текущего контекста безопасности имени входа. При использовании этой конфигурации при выполнении запроса связанного сервера в SQL1 с удаленного клиентского компьютера с именем Client1 учетные данные Windows сначала должны будут переходить с Client1 на SQL1 , а затем из SQL1 в SQL2 (поэтому это называется двойным прыжком). Дополнительные сведения см. в разделе Общие сведения о двойном прыжке Kerberos и обзоре ограниченного делегирования Kerberos.

Сбой входа для пользователя (пустой)

Эта ошибка возникает, когда пользователь безуспешно пытается войти в систему. Эта ошибка может возникнуть, если компьютер не подключен к сети. Например, может появилось сообщение об ошибке, похожее на следующее:

Пустая строка означает, что SQL Server пытались передать учетные данные службе подсистемы локального центра безопасности (LSASS), но не смогли из-за какой-то проблемы. Либо LSASS был недоступен, либо не удалось связаться с контроллером домена.

Проверьте журналы событий на клиенте и сервере на наличие сообщений, связанных с сетью или Active Directory, которые были зарегистрированы во время сбоя. Если вы найдете их, обратитесь к администратору домена, чтобы устранить проблемы.

«Сбой при входе в систему пользователя ‘(пусто)’»

Указание «null» может означать, что LSASS не может расшифровать маркер безопасности с помощью учетных данных SQL Server учетной записи службы. Основная причина этого условия заключается в том, что имя субъекта-службы связано с неправильной учетной записью.

Чтобы устранить проблему, сделайте следующее:

Используйте SQLCheck или Setspn.exe для диагностики и устранения проблем, связанных с spN.

Используйте sqlCheck , чтобы проверить, является ли учетная запись службы SQL доверенной для делегирования. Если в выходных данных указано, что учетная запись не является доверенной для делегирования, обратитесь к администратору Active Directory, чтобы включить делегирование для учетной записи.

Диагностика и устранение проблем с разрешением имен в системе доменных имен (DNS). Пример:

Связь с IP-адресом с помощью скриптов PowerShell:

• ping -a (используется -4 специально для IPv4 и -6 IPv6)
• ping -a

Используйте NSLookup , чтобы ввести имя локального и удаленного компьютера и IP-адрес несколько раз.

Найдите расхождения и несоответствия в возвращаемых результатах. Точность конфигурации DNS в сети важна для успешного SQL Server подключения. Неправильная запись DNS может привести к многочисленным проблемам с подключением позже.

Убедитесь, что брандмауэры или другие сетевые устройства не блокируют подключение клиента к контроллеру домена. Имена субъектов-служб хранятся в Active Directory. Если клиенты не могут взаимодействовать с каталогом, подключение не будет выполнено.

Дополнительные сведения об ошибке

В целях повышения безопасности сообщение об ошибке, возвращаемое клиенту, намеренно скрывает природу ошибки проверки подлинности. Однако в журнале ошибок SQL Server для соответствующей ошибки указано состояние, которое можно сопоставить с условиями сбоя проверки подлинности. Сравните состояние ошибки со следующим списком, чтобы определить причину ошибки входа.

Состояние	Описание
1	Сведения об ошибке недоступны. Это состояние обычно означает, что у вас нет разрешения на получение сведений об ошибке. За дополнительными сведениями обратитесь к администратору SQL Server.
2	Недопустимый идентификатор пользователя.
5	Недопустимый идентификатор пользователя.
6	Предпринята попытка использовать имя входа Windows при использовании проверки подлинности SQL Server.
7	Имя входа отключено, и пароль неверный.
8	Пароль неверный.
9	Недопустимый пароль.
11	Допустимое имя входа, но доступ к серверу не удался. Одной из возможных причин этой ошибки является то, что пользователь Windows имеет доступ к SQL Server в качестве члена группы локальных администраторов, но Windows не предоставляет учетные данные администратора. Чтобы установить соединение, запустите программу подключения от имени администратора, а затем добавьте имя пользователя Windows в SQL Server в качестве определенного имени входа.|
12	Допустимое имя входа, но доступ к серверу не удался.
18	Пароль должен быть изменен.
38, 46	Не удалось найти базу данных, запрошенную пользователем.
58	Если SQL Server настроен на использование только проверки подлинности Windows, а клиент пытается выполнить вход с использованием проверки подлинности SQL. Другая причина заключается в том, что идентификаторы безопасности не совпадают.
102–111	Ошибка AAD.
122–124	Сбой из-за пустого имени пользователя или пароля.
126	База данных, запрашиваемая пользователем, не существует.
132–133	Ошибка AAD.

Есть другие коды ошибок, которые означают непредвиденные внутренние ошибки обработки.

Более редкая возможная причина

Причина ошибки. Попытка входа с помощью проверки подлинности SQL завершилась сбоем. Сервер настроен только для проверка подлинности Windows. Его можно вернуть в следующих ситуациях.

Если сервер настроен для проверки подлинности в смешанном режиме, а подключение ODBC использует протокол TCP, а в соединении явно не указано, что соединение должно использовать доверенное соединение.

Если SQL Server настроен для проверки подлинности в смешанном режиме, а подключение ODBC использует именованные каналы, а учетные данные, используемые клиентом для открытия именованного канала, используются для автоматического олицетворения пользователя, а строка подключения явно не указывает использование доверенной проверки подлинности.

Чтобы решить эту проблему, включите в строку подключения параметр TRUSTED_CONNECTION = TRUE.

Примеры

В этом примере состояние ошибки проверки подлинности равно 8. Это означает, что пароль неверный.

Дата	Источник	Сообщение
2007-12-05 20:12:56.34	Вход в систему	Ошибка: 18456, серьезность: 14, состояние: 8.
2007-12-05 20:12:56.34	Вход в систему	Сбой входа для пользователя » «. [КЛИЕНТ: ]

Если SQL Server устанавливается в режиме аутентификации Windows, а затем переключается на аутентификацию SQL Server и Windows, то имя входа sa будет по умолчанию отключено. Это приводит к ошибке с состоянием 7: «Ошибка входа для пользователя sa». Чтобы включить имя для входа sa, выполните инструкции из статьи об изменении режима проверки подлинности сервера.

Источник

Иногда требуется настроить синхронизацию между базами 1с через каталог обмена. Но настройка не всегда так очевидна, как казалось бы…

В этой статье я привел решение ошибки «Каталог обмена информацией не существует» в случае, если сервер 1с установлен на Linux и Windows сервере.

• Решение для Linux сервера 1с
• Решение для Windows сервера и файлового режима работы 1с

Решение для сервера 1с на Linux на примере Centos Stream.

Скорее всего вы получаете одну из нескольких ошибок:

Прямое подключение к информационной базе недоступно на сервере под управлением ОС Linux — ошибка говорит сама за себя, нам потребуется настройка сетевого обмена.

Ошибка подключения: Каталог обмена информацией не существует — данная ошибка возникает из-за того, что при настройке обмена авторизация в сетевой папке происходит учетной записью usr1cv8 из под Linux.

Для решения данной проблемы нам придется смонтировать сетевую папку в Linux под учетной записью, под которой работает сервер 1с.

1) Расшариваем сетевую папку на вашем файловом сервере и даем права на запись для учетной записи guest.

У меня будет //192.168.128.32/public/1C_Share

2) Установим cifs-utils на Linux сервере 1с:

yum install cifs-utils #для Centos
apt install cifs-utils #для Ubuntu

3) Создадим каталог для обмена, в который будет монтироваться сетевая папка:

mkdir /1C_Share

4) Посмотрим uid пользователя usr1cv8, чтобы при монтировании указать его владельцем: каталога

less /etc/passwd

5) Смонтируем нашу сетевую папку в каталог 1С_Share:

mount -t cifs //192.168.128.32/public/1C_Share /1C_Share -o user=guest,password=,uid=993

Теперь в настройках 1с указываем каталог для обмена 1C_Share и смотрим есть ли подключение:

6) Сейчас сделаем так, чтобы сетевая папка в Linux монтировалась автоматически после перезагрузки:

nano /etc/fstab и в конфиге добавляем внизу

//192.168.128.32/public/1C_Share /1C_Share cifs username=guest,password=,uid=993,iocharset=utf8,nofail 0 0

Решение для сервера 1с установленном на Windows Server.

Здесь все гораздо проще. Нужно авторизоваться в сетевом каталоге под учетной записью с которой у вас запущена служба 1с. У меня это USR1CV8.

Для этого под пользователем USR1CV8 переходим в Панель управления — Диспетчер учетных данных — Учетные данные Windows и добавляем адрес сервера //192.168.128.32 с данными авторизации, которые вы указали на файловом сервере.

Если вдруг у вас появляется подобная ошибка при файловом режиме работы 1с, то вам не хватает прав на запись для вашей учетной записи в каталоге, в котором вы настраиваете обмен.

Стоит посмотреть права для пользователя на вкладке Безопасность:

Ошибка входа пользователя «SRVUSR1CV82

Модератор: Дмитрий Юхтимовский

---

---

---

---

---

Вернуться в Прочее

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

	Я
atlantika 06.12.22 — 15:49	На 1С серверах идут неудачные авторизации с  других серверов 1С под учётной записью USR1CV8. В чем может быть дело? Внешне с работой в 1С нет никаких проблем. Сервер лицензирования отдельный, сервер SQL и 1С — вместе. Прошу консультации.
timurhv 1 — 06.12.22 — 15:51	Тома хранения файлов на этом же сервере прописаны?
atlantika 2 — 06.12.22 — 15:55	тома хранения файлов на сервере с базами 1С
fbear 3 — 06.12.22 — 15:58	Может нелицензионные ищет установки?
lodger 4 — 06.12.22 — 16:00	или зловреды https://habr.com/ru/post/695586/
atlantika 5 — 06.12.22 — 16:00	а раньше не искал чтоли? Проблема последних 2-х месяцев. Если что то такое известно из новостей по платформе — подскажите что помните — мне сисадмину ответить надо…
atlantika 6 — 06.12.22 — 16:12	(4) спасибо. Почитаем, просветимся…
1Сергей 7 — 06.12.22 — 16:19	(0) А где вы видите эти авторизации?
atlantika 8 — 06.12.22 — 16:25	(7) в системных сообщениях, в журнале винды регистрируется… как так сисадмин объяснил. Я эту тему не трогаю, поэтому могла неправильно пересказать.
1Сергей 9 — 06.12.22 — 16:29	Не знал что агент 1С туда логирует авторизации…
atlantika 10 — 06.12.22 — 16:37	(9) на сервере — просмотр событий/журнал виндоуз / безопасность… и по нескольку строк на каждую минуту. …. Учетная запись, которой не удалось выполнить вход:     ИД безопасности:        NULL SID     Имя учетной записи:        USR1CV8     Домен учетной записи:    …..
1Сергей 11 — 06.12.22 — 16:42	(10) а, это не в 1С, а на комп кто-то ломится. Да, подозрительная херня
atlantika 12 — 07.12.22 — 08:36	Коллеги подсказали, что это вероятно новые механизмы платформы, в последних релизах платформы переработали проверки лицензирования. И что еще надо заменить локальных пользователей на одного доменного. Буду пробовать сегодня.
atlantika 13 — 07.12.22 — 11:16	Доменный пользователь спас. Надо только незабыть дать ему права на папку 1С и папку с файлами )).
fbear 14 — 07.12.22 — 11:18	2(13) а чем спас, тем что теперь 1с будет лазить по другим серверам без ошибок входа? )
mistеr 15 — 07.12.22 — 11:32	(5) Кто-то где-то прописал сетевой путь, вот и дергается постоянно.
atlantika 16 — 09.12.22 — 14:12	(15) Где например? путь на сервер лицензирования? это явно не в коде… Теперь проблема в том, что у этого пользователя быстро растет папка темп, и админы настаивают, что я должна ограничить это средствами 1С, настроить базу 1С. Разве это возможно? у нас сервер ПРОФ.

Ошибка при запуске 1С «Ошибка при выполнении операции с информационной базой. Ошибка СУБД: Microsoft SQL ServerNativeClien 10.0: Ошибка входа пользователя «DB_SRVUSR1CV8».

07.03.2016 12:12

Александр Логачев 07.03.2016 18:03
При установке новой платформы если пароль от сервиса не известен, не устанавливайте сервер как сервис. Потом в реестре строку запуска сервиса поменяйте на новый путь.
Имя Цитировать 0