Доброго времени уважаемые форумчане.
Суть проблемы:
С недавнего времени перестали выполнятся групповые политики в домене у пользователей.
С логах системы у клиента ошибка:
Сбой обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена. Это может быть временным явлением. Как только компьютеру удастся подключиться к контроллеру домена и групповая политика будет
обработана успешно, будет создано сообщение об успехе. Если это сообщение не появляется в течение нескольких часов, обратитесь к администратору.
Не удалось успешно обновить политику пользователя. Обнаружены следующие ошибки:
Ошибка при обработке групповой политики. Не удалось пройти проверку подлинности в службе каталогов Active Directory на контроллере домена. (Ошибка при выполнении привязки LDAP Bind). На вкладке «Подробности» можно найти код и описание
ошибки.
Подробности:
Посмотрев по статье:
Event ID 1006 — Group Policy Preprocessing (Active Directory)
Как-то бред с неправильными учетными данными, даже поменял пароль. Сервер по сети доступен, сетевые папки видны:
Доступ к ним есть.
На сервере в событиях безопасности формируется аудит отказа:
Учетной записи не удалось выполнить вход в систему.
Субъект:
ИД безопасности:
NULL SID
Имя учетной записи:
—
Домен учетной записи:
—
Код входа:
0x0
Тип входа: 3
Учетная запись, которой не удалось выполнить вход:
ИД безопасности:
NULL SID
Имя учетной записи:
CAB2$
Домен учетной записи:
DOMAIN.LOCAL
Сведения об ошибке:
Причина ошибки:
Выбранный режим входа для данного пользователя на этом компьютере не предусмотрен.
Состояние:
0xC000015B
Подсостояние:
0x0
Сведения о процессе:
Идентификатор процесса вызывающей стороны:
0x0
Имя процесса вызывающей стороны:
—
Сведения о сети:
Имя рабочей станции:
—
Сетевой адрес источника:
192.168.1.16
Порт источника:
50404
Сведения о проверке подлинности:
Процесс входа:
Kerberos
Пакет проверки подлинности:
Kerberos
Промежуточные службы:
—
Имя пакета (только NTLM):
—
Длина ключа:
0
Данное событие возникает при неудачной попытке входа. Оно регистрируется на компьютере, попытка доступа к которому была выполнена.
Поля «Субъект» указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба «Сервер», или локальный процесс, такой как Winlogon.exe или Services.exe.
В поле «Тип входа» указан тип выполненного входа. Наиболее распространенными являются типы 2 (интерактивный) и 3 (сетевой).
В полях «Сведения о процессе» указано, какая учетная запись и процесс в системе выполнили запрос на вход.
Поля «Сведения о сети» указывают на источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.
Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
— В поле «Промежуточные службы» указано, какие промежуточные службы участвовали в данном запросе на вход.
— Поле «Имя пакета» указывает на подпротокол, использованный с протоколами NTLM.
— Поле «Длина ключа» содержит длину созданного сеансового ключа. Это поле может иметь значение «0», если сеансовый ключ не запрашивался.
I looked everywhere for a solution to my problem but still didn’t find it.
I have these two simple files as sladp.conf and mytree.ldif and when i try to add something to mytree.ldif it keeps asking me for a password (which i believe is roopw defined in slapd.conf) but it doesn’t work.
I really need help with this.
These are my files:
slapd.conf
database dbd
suffix "dc=ers,dc=uminho,dc=pt"
rootdn "cn=Manager,dc=ers,dc=uminho,dc=pt"
rootpw ersadmin
directory /usr/local/var/openldap-data
mytree.ldif
dn: dc=ers, dc=uminho, dc=pt
objectclass: dcObject
objectclass: organization
o: ERS
dc: ers
dn: cn=Manager,dc=ers,dc=uminho,dc=pt
objectclass: organizationalRole
cn: Manager
And this is what i’m trying to do and my response:
sudo ldapadd -x -D "cn=Manager,dc=ers,dc=uminho,dc=pt" -W -f /etc/ldap/mytree.ldif
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
I already tried to encrypt the password using
slappasswd -h {SHA} -s ersadmin
and changing my slapd.conf file
password-hash {SHA}
rootpw {SHA}pLEBIPx4rW3eebpwACBGAZkNH4CVBRGW
but it didn’t work. Thanks in advance.
Hey Guys,
I have setup a Windows Server 2008 R2 server running LDS. I have an LDS Instance running on 10001 (LDAP) and 20001 (LDAPS).
I added a user account using the following:
dn: CN=testaccount,CN=Users,DC=domain,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: testaccount
cn: testaccount
displayName: My Test Account
userPassword: Passw0rd
When I attempt to bind to this account using
ldp.exe using «Simple Bind» over LDAP (not secure LDAP) using the following credentials I get an error:
username: CN=testaccount,CN=Users,DC=domain,DC=ADAM
password: Passw0rd
————
res = ldap_simple_bind_s(ld, ‘CN=testaccount,CN=Users,DC=domain,DC=ADAM’, <unavailable>); // v.3
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 2030, v1db0
Error 0x8009030C The logon attempt failed
————
I read from multiple places on the internet that by default when you associate a password to an account — the account is disabled. I also know that this error can be related to the user account being disabled — please see:
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/44d29c43-4203-400a-bff4-c488da5c5f57/
However the attribute which sets the account password to disabled «msDS-UserAccountDisabled» is not associated with the user class object in the schema. If I associate it and set the attribute to False on «CN=testaccount,CN=Users,DC=domain,DC=ADAM»
it does not resolve the problem.
In Active Directory items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password are all associated with an attribute called userAccountControl. This attribute has an integer set to it.. 512 is a normal account.
Different values perform different functionality, please see
http://support.microsoft.com/kb/305144
AD LDS (ADAM) does not support the userAccountControl attribute. Instead, AD LDS uses several individual attributes to hold the information that is contained in the flags of the userAccountControl attribute. For a list of these attributes please refer
to the following MSDN article:
http://msdn.microsoft.com/en-us/library/aa772124.aspx
Why are these attributes not associated with the user class object and how come when I associate them they do not work. I need to be able to authenticate with ADAM user accounts in my AD LDS Instance.
Kind Regards,
Clint Boessen MVP — Exchange Server, MCSE, MCITPx4, Dip Network Engineering
Perth, Western Australia
Blog: http://clintboessen.blogspot.com/
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Hey Guys,
I have setup a Windows Server 2008 R2 server running LDS. I have an LDS Instance running on 10001 (LDAP) and 20001 (LDAPS).
I added a user account using the following:
dn: CN=testaccount,CN=Users,DC=domain,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: testaccount
cn: testaccount
displayName: My Test Account
userPassword: Passw0rd
When I attempt to bind to this account using
ldp.exe using «Simple Bind» over LDAP (not secure LDAP) using the following credentials I get an error:
username: CN=testaccount,CN=Users,DC=domain,DC=ADAM
password: Passw0rd
————
res = ldap_simple_bind_s(ld, ‘CN=testaccount,CN=Users,DC=domain,DC=ADAM’, <unavailable>); // v.3
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 2030, v1db0
Error 0x8009030C The logon attempt failed
————
I read from multiple places on the internet that by default when you associate a password to an account — the account is disabled. I also know that this error can be related to the user account being disabled — please see:
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/44d29c43-4203-400a-bff4-c488da5c5f57/
However the attribute which sets the account password to disabled «msDS-UserAccountDisabled» is not associated with the user class object in the schema. If I associate it and set the attribute to False on «CN=testaccount,CN=Users,DC=domain,DC=ADAM»
it does not resolve the problem.
In Active Directory items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password are all associated with an attribute called userAccountControl. This attribute has an integer set to it.. 512 is a normal account.
Different values perform different functionality, please see
http://support.microsoft.com/kb/305144
AD LDS (ADAM) does not support the userAccountControl attribute. Instead, AD LDS uses several individual attributes to hold the information that is contained in the flags of the userAccountControl attribute. For a list of these attributes please refer
to the following MSDN article:
http://msdn.microsoft.com/en-us/library/aa772124.aspx
Why are these attributes not associated with the user class object and how come when I associate them they do not work. I need to be able to authenticate with ADAM user accounts in my AD LDS Instance.
Kind Regards,
Clint Boessen MVP — Exchange Server, MCSE, MCITPx4, Dip Network Engineering
Perth, Western Australia
Blog: http://clintboessen.blogspot.com/
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Problem
Users cannot login to FEM
Symptom
FEM returns a «LDAP: error code 49 — Invalid Credentials»
Cause
1. The credential of the bind user in one of the Directory Configurations is incorrect.
2. The credential of bootstrap user is incorrect
Diagnosing The Problem
Check for Directory Configuration bind user credential is incorrect
1. Check the ping page and confirm that CE has started successfully with no errors.
2. Attempt to login through FEM with a valid user. If the login fails with a LDAP error 49, at least one of the directory configuration bind user credential is incorrect.
Check for bootstrap user credential is incorrect
1. Check the ping page and confirm that CE has started, but the ping page should give a LDAP error 49.
2. Attempt to login through FEM with a valid user. If the login fails with a LDAP error 49, the bootstrap user crenential is incorrect.
Resolving The Problem
Using a third-party tool, login to the LDAP server with directory configuration bind user credential. If login is unsuccessful, contact an LDAP administrator to get the correct password. If login is successful, the bootstrap or bind user credential is incorrect.
Directory Configuration bind user credential is incorrect
Use the GCDUtil tool to modify the Directory Configuration bind user password
Bootstrap user credential is incorrect
Start CMUI tool, run the bootstrap task to update the bootstrap user credentials, and then redeploy CE.
[{«Product»:{«code»:»SSNVNV»,»label»:»FileNet Content Manager»},»Business Unit»:{«code»:»BU053″,»label»:»Cloud & Data Platform»},»Component»:»Content Engine»,»Platform»:[{«code»:»PF033″,»label»:»Windows»},{«code»:»PF002″,»label»:»AIX»},{«code»:»PF010″,»label»:»HP-UX»},{«code»:»PF016″,»label»:»Linux»},{«code»:»PF027″,»label»:»Solaris»}],»Version»:»4.5;4.5.1″,»Edition»:»»,»Line of Business»:{«code»:»LOB45″,»label»:»Automation»}}]
I’m trying to set up an openLdap server and after following the instructions I’m stuck at the point where I can’t add any data.
The error I’m getting is
ldap_bind: Invalid credentials (49)
Please help me in this issue. And be patient while reading the debug data and the slapd.conf file because they are quite long.
My system is: Red Hat Enterprise Linux 6.0
Installed openLdap using yum openldap*.
Here is my slapd.conf file:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# modulepath /usr/lib/openldap # or /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
## To load this module, you have to install openldap-server-sql first
# moduleload back_sql.la
## Following two modules can't be loaded simultaneously
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix dc=ttsbroot,dc=teleotele
#checkpoint 1024 15
rootdn cn=shamal,dc=ttsbroot,dc=teleotele
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {crypt}49/WKVk.6oz3o
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@EXAMPLE.COM
# enable monitoring
database monitor
# allow onlu rootdn to read the monitor
access to * by * write by * read by * search by * auth
I’m adding the debug data returned when I added -d 255 argument.
[root@TTSBROOT Documents]# ldapadd -D "cn=shamal,dc=TTSBROOT,dc=teleotele" -W -x -a -f teleotele.ldif -d 255
ldap_create
Enter LDAP Password:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 127.0.0.1:389
ldap_pvt_connect: fd: 4 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x18345d0 ptr=0x18345d0 end=0x1834612 len=66
0000: 30 84 00 00 00 3c 02 01 01 60 84 00 00 00 33 02 0....<...`....3.
0010: 01 03 04 22 63 6e 3d 73 68 61 6d 61 6c 2c 64 63 ..."cn=shamal,dc
0020: 3d 54 54 53 42 52 4f 4f 54 2c 64 63 3d 74 65 6c =TTSBROOT,dc=tel
0030: 65 6f 74 65 6c 65 80 0a 73 68 61 6d 61 6c 31 32 eotele..shamal12
0040: 33 34 34
ber_scanf fmt ({i) ber:
ber_dump: buf=0x18345d0 ptr=0x18345d9 end=0x1834612 len=57
0000: 60 84 00 00 00 33 02 01 03 04 22 63 6e 3d 73 68 `....3...."cn=sh
0010: 61 6d 61 6c 2c 64 63 3d 54 54 53 42 52 4f 4f 54 amal,dc=TTSBROOT
0020: 2c 64 63 3d 74 65 6c 65 6f 74 65 6c 65 80 0a 73 ,dc=teleotele..s
0030: 68 61 6d 61 6c 31 32 33 34 hamal1234
ber_flush2: 66 bytes to sd 4
0000: 30 84 00 00 00 3c 02 01 01 60 84 00 00 00 33 02 0....<...`....3.
0010: 01 03 04 22 63 6e 3d 73 68 61 6d 61 6c 2c 64 63 ..."cn=shamal,dc
0020: 3d 54 54 53 42 52 4f 4f 54 2c 64 63 3d 74 65 6c =TTSBROOT,dc=tel
0030: 65 6f 74 65 6c 65 80 0a 73 68 61 6d 61 6c 31 32 eotele..shamal12
0040: 33 34 34
ldap_write: want=66, written=66
0000: 30 84 00 00 00 3c 02 01 01 60 84 00 00 00 33 02 0....<...`....3.
0010: 01 03 04 22 63 6e 3d 73 68 61 6d 61 6c 2c 64 63 ..."cn=shamal,dc
0020: 3d 54 54 53 42 52 4f 4f 54 2c 64 63 3d 74 65 6c =TTSBROOT,dc=tel
0030: 65 6f 74 65 6c 65 80 0a 73 68 61 6d 61 6c 31 32 eotele..shamal12
0040: 33 34 34
ldap_result ld 0x182c3e0 msgid 1
wait4msg ld 0x182c3e0 msgid 1 (infinite timeout)
wait4msg continue ld 0x182c3e0 msgid 1 all 1
** ld 0x182c3e0 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Fri Apr 22 14:24:17 2011
** ld 0x182c3e0 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x182c3e0 request count 1 (abandoned 0)
** ld 0x182c3e0 Response Queue:
Empty
ld 0x182c3e0 response count 0
ldap_chkResponseList ld 0x182c3e0 msgid 1 all 1
ldap_chkResponseList returns ld 0x182c3e0 NULL
ldap_int_select
read1msg: ld 0x182c3e0 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
0000: 30 84 00 00 00 10 02 01 0.......
ldap_read: want=14, got=14
0000: 01 61 84 00 00 00 07 0a 01 31 04 00 04 00 .a.......1....
ber_get_next: tag 0x30 len 16 contents:
ber_dump: buf=0x1835a50 ptr=0x1835a50 end=0x1835a60 len=16
0000: 02 01 01 61 84 00 00 00 07 0a 01 31 04 00 04 00 ...a.......1....
read1msg: ld 0x182c3e0 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x1835a50 ptr=0x1835a53 end=0x1835a60 len=13
0000: 61 84 00 00 00 07 0a 01 31 04 00 04 00 a.......1....
read1msg: ld 0x182c3e0 0 new referrals
read1msg: mark request completed, ld 0x182c3e0 msgid 1
request done: ld 0x182c3e0 msgid 1
res_errno: 49, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x1835a50 ptr=0x1835a53 end=0x1835a60 len=13
0000: 61 84 00 00 00 07 0a 01 31 04 00 04 00 a.......1....
ber_scanf fmt (}) ber:
ber_dump: buf=0x1835a50 ptr=0x1835a60 end=0x1835a60 len=0
ldap_msgfree
ldap_err2string
ldap_bind: Invalid credentials (49)
Steps to reproduce
- Connect to LDAP Server, Configuration OK. 301 Users found, they show up in User category.
2.Try to log in with a user, using the ‘username’ displayed in NC
3.Wrong Password shows up and user is rejected, log says Bind failed: 49: Invalid credentials
Expected behaviour
User should be authenticated and logged in
Actual behaviour
User is rejected
Server configuration
Operating system:
Ubuntu 12.04.5 LTS
Web server:
Apache2
Database:
MySql
PHP version:
PHP 7.0.15-0ubuntu0.16.04.4
Nextcloud version: (see Nextcloud admin page)
11,0,2,7
Updated from an older Nextcloud/ownCloud or fresh install:
Fresh install
Where did you install Nextcloud from:
Tar from official website: Nextcloud-11.0.2.tar.bz2
Signing status:
Signing status
Login as admin user into your Nextcloud and access
http://example.com/index.php/settings/integrity/failed
paste the results here.
No errors have been found.
List of activated apps:
App list
If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your Nextcloud installation folder
Enabled:
- activity: 2.4.1
- admin_audit: 1.1.0
- comments: 1.1.0
- dav: 1.1.1
- federatedfilesharing: 1.1.1
- federation: 1.1.1
- files: 1.6.1
- files_pdfviewer: 1.0.1
- files_sharing: 1.1.1
- files_texteditor: 2.2
- files_trashbin: 1.1.0
- files_versions: 1.4.0
- files_videoplayer: 1.0.0
- firstrunwizard: 2.0
- gallery: 16.0.0
- logreader: 2.0.0
- lookup_server_connector: 1.0.0
- nextcloud_announcements: 1.0
- notifications: 1.0.1
- provisioning_api: 1.1.0
- serverinfo: 1.1.1
- sharebymail: 1.0.1
- survey_client: 0.1.5
- systemtags: 1.1.3
- theming: 1.1.1
- twofactor_backupcodes: 1.0.0
- updatenotification: 1.1.1
- user_external: 0.4
- user_ldap: 1.1.2
- workflowengine: 1.1.1
Disabled: - encryption
- external
- files_accesscontrol
- files_automatedtagging
- files_external
- files_retention
- password_policy
- templateeditor
- user_saml
The content of config/config.php:
Config report
If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your Nextcloud installation folder
or
Insert your config.php content here
(Without the database password, passwordsalt and secret)
{
"system": {
"instanceid": "ocqigl38jpv6",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"xxx.xxx.org"
],
"datadirectory": "/var/www/nextcloud/data",
"overwrite.cli.url": "https://xxx.xxx.org/nextcloud",
"dbtype": "mysql",
"version": "11.0.2.7",
"dbname": "nextcloud",
"dbhost": "localhost",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"logtimezone": "UTC",
"installed": true,
"ldapIgnoreNamingRules": false,
"ldapProviderFactory": "OCAUser_LDAPLDAPProviderFactory"
}
}
Are you using external storage, if yes which one: local/smb/sftp/…
no
Are you using encryption: yes/no
no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…
LDAP:
Kerberos with LDAP as login agent
LDAP configuration (delete this part if not used)
LDAP config
With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your Nextcloud installation folder
Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';
Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.
Client configuration
Browser:
Operating system:
Logs
Web server error log
Web server error log
Insert your webserver log here
Nextcloud log (data/nextcloud.log)
Nextcloud log
+——————————-+————————————————————————————-+
| Configuration | s01 |
+——————————-+————————————————————————————-+
| hasMemberOfFilterSupport | |
| hasPagedResultSupport | |
| homeFolderNamingRule | |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | cn=ADMIN,dc=ds,dc=local |
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | dc=ds,dc=local |
| ldapBaseGroups | dc=ds,dc=local |
| ldapBaseUsers | ou=people,dc=ds,dc=local |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 1 |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | mail |
| ldapExperiencedAdmin | 0 |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | |
| ldapExpertUsernameAttr | uid |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | (&(|(objectclass=posixGroup))) |
| ldapGroupFilterGroups | |
| ldapGroupFilterMode | 1 |
| ldapGroupFilterObjectclass | posixGroup |
| ldapGroupMemberAssocAttr | memberUid |
| ldapHost | teller.ds.local |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | (&(|(objectclass=inetOrgPerson))(uid=%uid)) |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 0 |
| ldapLoginFilterMode | 1 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 1 |
| ldapOverrideMainServer | |
| ldapPagingSize | 1000 |
| ldapPort | 389 |
| ldapQuotaAttribute | |
| ldapQuotaDefault | |
| ldapTLS | 0 |
| ldapUserDisplayName | cn |
| ldapUserDisplayName2 | |
| ldapUserFilter | (|(objectclass=inetOrgPerson)(objectclass=krb5Principal)(objectclass=posixAccount)) |
| ldapUserFilterGroups | |
| ldapUserFilterMode | 0 |
| ldapUserFilterObjectclass | inetOrgPerson;krb5Principal;posixAccount |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 1 |
| turnOnPasswordChange | 0 |
| useMemberOfToDetectMembership | 1 |
+——————————-+————————————————————————————-+
+——————————-+—————+
| Configuration | s02 |
+——————————-+—————+
| hasMemberOfFilterSupport | 0 |
| hasPagedResultSupport | |
| homeFolderNamingRule | |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | |
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | |
| ldapBaseGroups | |
| ldapBaseUsers | |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 0 |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | |
| ldapExperiencedAdmin | 0 |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | |
| ldapExpertUsernameAttr | |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | |
| ldapGroupFilterGroups | |
| ldapGroupFilterMode | 0 |
| ldapGroupFilterObjectclass | |
| ldapGroupMemberAssocAttr | uniqueMember |
| ldapHost | |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 0 |
| ldapLoginFilterMode | 0 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 0 |
| ldapOverrideMainServer | |
| ldapPagingSize | 500 |
| ldapPort | |
| ldapQuotaAttribute | |
| ldapQuotaDefault | |
| ldapTLS | 0 |
| ldapUserDisplayName | displayName |
| ldapUserDisplayName2 | |
| ldapUserFilter | |
| ldapUserFilterGroups | |
| ldapUserFilterMode | 0 |
| ldapUserFilterObjectclass | |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 0 |
| turnOnPasswordChange | 0 |
| useMemberOfToDetectMembership | 1 |
+——————————-+—————+
Browser log
Browser log
Insert your browser log here, this could for example include:
a) The javascript console log
b) The network log
c) ...
Due to personal info and IP’s I can’t admitt the log. Putting warnings and errors here.
Warning user_ldap Bind failed: 49: Invalid credentials
Warning core Login failed: ‘Username’
Error index OCServerNotAvailableException: Connection to LDAP server could not be established (This one might have showed up when I was tinkering and is probably not a permanent one)
Error PHP ldap_search(): Partial search results returned: Sizelimit exceeded at /var/www/nextcloud/apps/user_ldap/lib/LDAP.php#293
Ну вот черным по белому: код 49 — Invalid Credentials. Проблема с методом аутентификации (код 7 — authMethodNotSupported) вылезла бы как-то так: «Unsupported auth method ()» Opens a new window. С LDAP ошибкой 49 связаны коды системных ошибок Opens a new window, которые могут прояснить, почему же имя/пароль — «Invalid». Выборка наиболее распространенных ошибок, связанных с AD есть в IBM’овской документации Opens a new window. Увидеть эти коды можно в майкрософтовской утилите LDP при попытке осуществить LDAP привязку (bind). Вот, к примеру, что отвечает 2008R2 AD при вводе несуществующего имени пользователя:
0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 0)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
{NtAuthIdentity: User='nonexist.user'; Pwd=<unavailable>; domain = 'mydomain'}
Error <49>: ldap_bind_s() failed: Неправильные учетные данные.
Server error: 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1
Error 0x8009030C Попытка входа в систему неудачна
Смотрим System Error Codes (1300-1699) Opens a new window: ERROR_LOGON_FAILURE 1326 (0x52E) — The user name or password is incorrect. Совпадает
На всякий случай коды ошибок LDAP:
- RFC-4511 LDAPv3 — LDAP Result Codes Opens a new window
- MS LDAP Reference — Constants — Return Values Opens a new window
Was this post helpful?
thumb_up
thumb_down
Уважаемые администраторы прошу вашей помощи, начинающему в изучении FreeBSD 8.0. Взялся настраивать PDC по видео взятого с торрента. Возникла проблема при выполнении команды:
# ldapadd -x -D «cn=root,dc=vishagi,dc=ru» -W 12345 -f ldap.ldif
Выходит следующее: ldap_bind: Invalid credentials (49)
Содержимое файла ldap.ldif:
dn: dc=vishagi,dc=ru
objectClass: dcObject
objectClass: organization
objectClass: top
dc: vishagi
o: ru
dn: ou=users,dc=vishagi,dc=ru
objectClass: top
objectClass: organizationUnit
ou: users
dn: ou=groups,dc=vishagi,dc=ru
objectClass: top
objectClass: organizationUnit
ou: groups
dn: ou=computers,dc=vishagi,dc=ru
objectClass: top
objectClass: organizationUnit
ou: computers
Содержимое файла: rc.conf
# — sysinstall generated deltas — # Thu May 12 04:13:03 2011
# Created: Thu May 12 04:13:03 2011
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
defaultrouter=»192.168.1.1″
hostname=»pdc.vishagi.ru»
ifconfig_em0=»inet 192.168.1.198 netmask 255.255.255.0″
sshd_enable=»YES»
named_enable=»YES»
slapd_enable=»YES»
slapd_flags=’-h «ldapi://%2fvar%2frun%2fopenldap%2ldapi/ ldap://0.0.0.0/ ldap://127.0.0.1/»‘
Содержимое файла slapd.conf :
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/misc.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/openldap.schema
#include /usr/local/etc/openldap/schema
#include /usr/local/etc/openldap/schema
#include /usr/local/etc/openldap/schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
modulepath /usr/local/libexec/openldap
#moduleload back_bdb
# moduleload back_ldap
moduleload back_ldbm
# moduleload back_passwd
# moduleload back_shell
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base=»» by * read
# access to dn.base=»cn=Subschema» by * read
access to attrs=userPassword
by self write
# by users read
by anonymous auth
by * none
access to *
by self write
# by users read
by anonymous read
by * none
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., «access to * by * read»)
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# BDB database definitions
#######################################################################
database ldbm
suffix «dc=my-vishagi,dc=ru»
rootdn «cn=root,dc=my-vishagi,dc=ru»
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {SSHA}xh79hI71Ep25ZI0PztJtToa9Q4z0V6e2
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/db/openldap-data
# Indices to maintain
index objectClass eq
index cn eq
На данном этапе все файлы выглядят как выложено. Прошу вашей помощи в разъяснении данной проблемы и решении её. Заранее Спасибо всем !!!
На ввод данной команды: # ldapadd -x -D «cn=root,dc=vishagi,dc=ru» -W 12345 -f ldap.ldif
Должно появиться следующее:
adding new entry «dc=vishagi,dc=ru»
ldapadd: Already exists (68)
Доброго времени уважаемые форумчане.
Суть проблемы:
С недавнего времени перестали выполнятся групповые политики в домене у пользователей.
С логах системы у клиента ошибка:
Сбой обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена. Это может быть временным явлением. Как только компьютеру удастся подключиться к контроллеру домена и групповая политика будет
обработана успешно, будет создано сообщение об успехе. Если это сообщение не появляется в течение нескольких часов, обратитесь к администратору.
Не удалось успешно обновить политику пользователя. Обнаружены следующие ошибки:
Ошибка при обработке групповой политики. Не удалось пройти проверку подлинности в службе каталогов Active Directory на контроллере домена. (Ошибка при выполнении привязки LDAP Bind). На вкладке «Подробности» можно найти код и описание
ошибки.
Подробности:
Посмотрев по статье:
Event ID 1006 — Group Policy Preprocessing (Active Directory)
Как-то бред с неправильными учетными данными, даже поменял пароль. Сервер по сети доступен, сетевые папки видны:
Доступ к ним есть.
На сервере в событиях безопасности формируется аудит отказа:
Учетной записи не удалось выполнить вход в систему.
Субъект:
ИД безопасности:
NULL SID
Имя учетной записи:
—
Домен учетной записи:
—
Код входа:
0x0
Тип входа: 3
Учетная запись, которой не удалось выполнить вход:
ИД безопасности:
NULL SID
Имя учетной записи:
CAB2$
Домен учетной записи:
DOMAIN.LOCAL
Сведения об ошибке:
Причина ошибки:
Выбранный режим входа для данного пользователя на этом компьютере не предусмотрен.
Состояние:
0xC000015B
Подсостояние:
0x0
Сведения о процессе:
Идентификатор процесса вызывающей стороны:
0x0
Имя процесса вызывающей стороны:
—
Сведения о сети:
Имя рабочей станции:
—
Сетевой адрес источника:
192.168.1.16
Порт источника:
50404
Сведения о проверке подлинности:
Процесс входа:
Kerberos
Пакет проверки подлинности:
Kerberos
Промежуточные службы:
—
Имя пакета (только NTLM):
—
Длина ключа:
0
Данное событие возникает при неудачной попытке входа. Оно регистрируется на компьютере, попытка доступа к которому была выполнена.
Поля «Субъект» указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба «Сервер», или локальный процесс, такой как Winlogon.exe или Services.exe.
В поле «Тип входа» указан тип выполненного входа. Наиболее распространенными являются типы 2 (интерактивный) и 3 (сетевой).
В полях «Сведения о процессе» указано, какая учетная запись и процесс в системе выполнили запрос на вход.
Поля «Сведения о сети» указывают на источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.
Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
— В поле «Промежуточные службы» указано, какие промежуточные службы участвовали в данном запросе на вход.
— Поле «Имя пакета» указывает на подпротокол, использованный с протоколами NTLM.
— Поле «Длина ключа» содержит длину созданного сеансового ключа. Это поле может иметь значение «0», если сеансовый ключ не запрашивался.
I don’t see an obvious problem with the above.
It’s possible your ldap.conf is being overridden, but the command-line options will take precedence, ldapsearch will ignore BINDDN in the main ldap.conf, so the only parameter that could be wrong is the URI.
(The order is ETCDIR/ldap.conf then ~/ldaprc or ~/.ldaprc and then ldaprc in the current directory, though there environment variables which can influence this too, see man ldapconf.)
Try an explicit URI:
ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base -H ldap://localhost
or prevent defaults with:
LDAPNOINIT=1 ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
If that doesn’t work, then some troubleshooting (you’ll probably need the full path to the slapd binary for these):
-
make sure your
slapd.confis being used and is correct (as root)slapd -T test -f slapd.conf -d 65535You may have a left-over or default
slapd.dconfiguration directory which takes preference over yourslapd.conf(unless you specify your config explicitly with-f,slapd.confis officially deprecated in OpenLDAP-2.4). If you don’t get several pages of output then your binaries were built without debug support. -
stop OpenLDAP, then manually start
slapdin a separate terminal/console with debug enabled (as root, ^C to quit)slapd -h ldap://localhost -d 481then retry the search and see if you can spot the problem (there will be a lot of schema noise in the start of the output unfortunately). (Note: running
slapdwithout the-u/-goptions can change file ownerships which can cause problems, you should usually use those options, probably-u ldap -g ldap) -
if debug is enabled, then try also
ldapsearch -v -d 63 -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
I’m trying to set up an openLdap server and after following the instructions I’m stuck at the point where I can’t add any data.
The error I’m getting is
ldap_bind: Invalid credentials (49)
Please help me in this issue. And be patient while reading the debug data and the slapd.conf file because they are quite long.
My system is: Red Hat Enterprise Linux 6.0
Installed openLdap using yum openldap*.
Here is my slapd.conf file:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# modulepath /usr/lib/openldap # or /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
## To load this module, you have to install openldap-server-sql first
# moduleload back_sql.la
## Following two modules can't be loaded simultaneously
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix dc=ttsbroot,dc=teleotele
#checkpoint 1024 15
rootdn cn=shamal,dc=ttsbroot,dc=teleotele
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {crypt}49/WKVk.6oz3o
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@EXAMPLE.COM
# enable monitoring
database monitor
# allow onlu rootdn to read the monitor
access to * by * write by * read by * search by * auth
I’m adding the debug data returned when I added -d 255 argument.
[root@TTSBROOT Documents]# ldapadd -D "cn=shamal,dc=TTSBROOT,dc=teleotele" -W -x -a -f teleotele.ldif -d 255
ldap_create
Enter LDAP Password:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 127.0.0.1:389
ldap_pvt_connect: fd: 4 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x18345d0 ptr=0x18345d0 end=0x1834612 len=66
0000: 30 84 00 00 00 3c 02 01 01 60 84 00 00 00 33 02 0....<...`....3.
0010: 01 03 04 22 63 6e 3d 73 68 61 6d 61 6c 2c 64 63 ..."cn=shamal,dc
0020: 3d 54 54 53 42 52 4f 4f 54 2c 64 63 3d 74 65 6c =TTSBROOT,dc=tel
0030: 65 6f 74 65 6c 65 80 0a 73 68 61 6d 61 6c 31 32 eotele..shamal12
0040: 33 34 34
ber_scanf fmt ({i) ber:
ber_dump: buf=0x18345d0 ptr=0x18345d9 end=0x1834612 len=57
0000: 60 84 00 00 00 33 02 01 03 04 22 63 6e 3d 73 68 `....3...."cn=sh
0010: 61 6d 61 6c 2c 64 63 3d 54 54 53 42 52 4f 4f 54 amal,dc=TTSBROOT
0020: 2c 64 63 3d 74 65 6c 65 6f 74 65 6c 65 80 0a 73 ,dc=teleotele..s
0030: 68 61 6d 61 6c 31 32 33 34 hamal1234
ber_flush2: 66 bytes to sd 4
0000: 30 84 00 00 00 3c 02 01 01 60 84 00 00 00 33 02 0....<...`....3.
0010: 01 03 04 22 63 6e 3d 73 68 61 6d 61 6c 2c 64 63 ..."cn=shamal,dc
0020: 3d 54 54 53 42 52 4f 4f 54 2c 64 63 3d 74 65 6c =TTSBROOT,dc=tel
0030: 65 6f 74 65 6c 65 80 0a 73 68 61 6d 61 6c 31 32 eotele..shamal12
0040: 33 34 34
ldap_write: want=66, written=66
0000: 30 84 00 00 00 3c 02 01 01 60 84 00 00 00 33 02 0....<...`....3.
0010: 01 03 04 22 63 6e 3d 73 68 61 6d 61 6c 2c 64 63 ..."cn=shamal,dc
0020: 3d 54 54 53 42 52 4f 4f 54 2c 64 63 3d 74 65 6c =TTSBROOT,dc=tel
0030: 65 6f 74 65 6c 65 80 0a 73 68 61 6d 61 6c 31 32 eotele..shamal12
0040: 33 34 34
ldap_result ld 0x182c3e0 msgid 1
wait4msg ld 0x182c3e0 msgid 1 (infinite timeout)
wait4msg continue ld 0x182c3e0 msgid 1 all 1
** ld 0x182c3e0 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Fri Apr 22 14:24:17 2011
** ld 0x182c3e0 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x182c3e0 request count 1 (abandoned 0)
** ld 0x182c3e0 Response Queue:
Empty
ld 0x182c3e0 response count 0
ldap_chkResponseList ld 0x182c3e0 msgid 1 all 1
ldap_chkResponseList returns ld 0x182c3e0 NULL
ldap_int_select
read1msg: ld 0x182c3e0 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
0000: 30 84 00 00 00 10 02 01 0.......
ldap_read: want=14, got=14
0000: 01 61 84 00 00 00 07 0a 01 31 04 00 04 00 .a.......1....
ber_get_next: tag 0x30 len 16 contents:
ber_dump: buf=0x1835a50 ptr=0x1835a50 end=0x1835a60 len=16
0000: 02 01 01 61 84 00 00 00 07 0a 01 31 04 00 04 00 ...a.......1....
read1msg: ld 0x182c3e0 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x1835a50 ptr=0x1835a53 end=0x1835a60 len=13
0000: 61 84 00 00 00 07 0a 01 31 04 00 04 00 a.......1....
read1msg: ld 0x182c3e0 0 new referrals
read1msg: mark request completed, ld 0x182c3e0 msgid 1
request done: ld 0x182c3e0 msgid 1
res_errno: 49, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x1835a50 ptr=0x1835a53 end=0x1835a60 len=13
0000: 61 84 00 00 00 07 0a 01 31 04 00 04 00 a.......1....
ber_scanf fmt (}) ber:
ber_dump: buf=0x1835a50 ptr=0x1835a60 end=0x1835a60 len=0
ldap_msgfree
ldap_err2string
ldap_bind: Invalid credentials (49)
The LDAP error code 49 occurs as a consequence of the authentication failure. You will find the reason behind the error and how to resolve it with an expert’s suggestion. Keep reading to gain a complete understanding.
Contents
- Why Do I See Ldap Error Code 49?
- – Authentication Failure
- – Other Account Authentication Related Problems
- How To Solve LDAP Error Code 49?
- – In Vcenter Server
- – Windows Installed Vcenter Server
- FAQs
- 1. What Is Ldap: Error Code 49 – 80090308?
- 2. What Does Ldap Error Code 49 – Invalid Credentials Mean?
- 3. How Do I Know if Ldap Is Running on My Server?
- 4. How Can I Check the LDAP Settings?
- Conclusion
Why Do I See Ldap Error Code 49?
You will see the ldap error code 49 because there might be an authentication failure. The error indicates an issue with the user account being connected to the LDAP server. Moreover, it can also occur if the connection you are using is having any kind of trouble.
– Authentication Failure
You see the error that says LDAP error code 49 means that it indicates the authentication failure. The authentication failure occurs when the VIP Enterprise Gateway tries to bind the LDAP host specified in the EGW use store settings.
What Normally happens is the Distinguished Name of the password is found to be invalid. The LDAP connection IP address returns the LDAP bind errors, which are then captured in VIP validation server logs. Look at an example of how that error might help you understand better when encountering one yourself.
ERROR “2019-08-29 15:46:47.335 GMT-0500” 10.4.5.240 LDAPSync 0 0 18478 “actor=LDAPSyncService,text=[LDAPStore:getConnection] Could not bind to the directory server.VsException [error=18478] [javax. naming.AuthenticationException: [LDAP: error code 49 – 8009030C: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 532, v3839 ]],op=Synchronization”
LDAP is used for authentication. It is used widely to build central authentication servers. Within a network, these servers contain all users’ passwords and usernames. All the services and applications can connect to the LDAP server to authorize and authenticate all the users.
In the LDAP authentication issue, you might see an error, i.e., ldap: error code 49 data 775, meaning a locked user account.
We will now discuss the subcodes of LDAP that we see when the LDAP error occurs in our system. Take a look at the LDAP Result Code 49 sub-codes for the Failure in Authentication that is given below to understand better.
701 account expired
773 username/password valid, must reset password
775 account lockout
525 user object not found
52e invalid password/credentia
530 time restriction in place
531 not permitted to logon at this workstation
532 password expired / DN username mismatch
533 account disabled
568 too many context identifiers etc
How To Solve LDAP Error Code 49?
To solve the LDAP error code 49, the user account’s password needs to be changed that is listed in the vmdird_syslog.log file. You might have to reset the password in both vCenter Server and in Windows installed vCenter Server to get rid of this error.
– In Vcenter Server
To change the password in the vCenter Server appliance, follow the given guidelines properly
- First, you must create a snapshot of the vCneter Server and the Platform Services Controller.
- After that, you will connect with the Platform Services Controller with the root credentials and SSH sessions.
- Then you need to run the command below to enable access to the Bash shell: set -enable true
- When you do that, you need to type shell and clock on Enter.
- Then, you need to run a command given below so that you can open the vdcadmintool
/usr/lib/vmware-vmdir/bin/vdcadmintool
You will then see the following options
0. exit
1. Test LDAP connectivity
2. Force start replication cycle
3. Reset account password
4. Set log level and mask
5. Set vmdir state
You should select option three from the list given above. Then you will enter the user account listed in the file that says vmdird-syslog.log.
After that, you need to make a note of the autogenerated password. Then Connect to the vCenter Server Appliance with the root credentials and the SSH servers, after which you should run the command below to access the Bash Shell.
After that, type Shell and then click on Enter. When you are done with the steps given above, you need to run the commands given below so that you will get the password updated.
cd HKEY_THIS_MACHINEservicesvmdir
set_value dcAccountPassword “new password”
quit
At last, you will need to restart the vCenter Server Appliance services, and you’ll be all set to go after that
– Windows Installed Vcenter Server
To change the password in the Windows-installed vCenter Server, follow the given guidelines properly:
- First, you must create a snapshot of the vCenter Server and the Platform Services Controller.
- On the Platform Services Controller, you will open the elevated command prompt.
- Afterward, you will run the command given below.
%VMWARE_CIS_HOME%vmdirdvdcadmintool.exe
Then you see the following options
0. exit
1. Test LDAP connectivity
2. Force start replication cycle
3. Reset account password
4. Set log level and mask
5. Set vmdir state
- From the list of options given above, you will pick option 3.
- Now you will enter the account listed in the file that says vmdir.log.
- You will then have to make a note of the password generated.
- You will then connect to the vCenter Server and then open Regedit.
- You will then navigate to the location: HLKMSystemCurrentControlsetServicesVMwareDirectoryService
- Afterward, you need to update the password for the key dcAccountPassword.
- When you are done with the changes made, save them and exit.
- Remember to restart the vCenter server services, and you will be ready.
FAQs
1. What Is Ldap: Error Code 49 – 80090308?
The LDAP: error code 49 – 80090308 indicates the invalidity of the credentials. You will see that this error message is a standard message too. This error will be seen as a standard message when incorrect credentials have been provided in the compiler.
2. What Does Ldap Error Code 49 – Invalid Credentials Mean?
The LDAP error code 49 – invalid credentials mean that a client’s application could not bind or authenticate to the LDAP servers. When the client attempts to integrate an application with JumpCloud’s LDAP server or whenever the client tries running a query, he may receive the LDAP: invalid credentials(49).
The same is the case with ldap error code 49 jira where LDAP Error 49 data means that the user’s credentials that have been set up to bind the LDAP directory with JIRA are incorrect
3. How Do I Know if Ldap Is Running on My Server?
You will know whether the LDAP is running on your server by navigating to settings by clicking the start button. From settings, go to the Control Panel. After this, open the NetIQ eDirectory Services tab. Afterwards, scroll down to nldap.dlm and look at the status column.
See what the column says. If the column displays Running, then that’s how you will know that the LDAP is running on your server.
4. How Can I Check the LDAP Settings?
You can check the LDAP settings by typing LDAP Policies at the command prompt of Ntdsutil.exe and pressing Enter button. Now write connections in the LDAP policy. In the prompt of server connection, you will now type Connect To Server<DNS name of server>.
When you are done writing the DNS server name, press Enter, and now you are good to go.
Conclusion
We have discussed the cause behind the error that says LDAP error code 49 and then discussed all the possible solutions to fix it. Let us summarise the article’s essential points, so you can recall them more easily in the future.
- The error LDAP error code 49 implies a problem when connecting to the LDAP server using the user account.
- The server produces this error whenever the attempt at initial login is made.
- The problem occurs either because of the wrong password or because the password needs to be changed.
- LDAP is used for the authentication that is used widely to build the central authentication servers. Within a network, these servers contain all users’ passwords and usernames.
- The issue can be resolved by altering the password for the user account, which is listed in the log file that says vmdird.syslog.
We are confident that you will be able to resolve the issue independently after reading the article. This article can be consulted whenever you need answers.
- Author
- Recent Posts
Your Go-To Resource for Learn & Build: CSS,JavaScript,HTML,PHP,C++ and MYSQL. Meet The Team