Insufficient access rights for the sync user
by Theodotos Andreou
I am trying to create a sync agreement between an AD server and a 389
directory server. I am following the "Red Hat Directory Server 8.1
Administration Guide"
The Guide instruct you to create a sync user under cn=config like this:
dn: cn=sync user,cn=config
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: sync user
sn: SU
userPassword: secret
passwordExpirationTime: 20380119031407Z
I added the user using an ldif file:
[root@directory ~]# cat syncuser.ldif
dn: cn=sync user,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: sync user
sn: syncuser
userPassword: secret
passwordExpirationTime: 20380119031407Z
It also says that you should create an ACI rule so that it cam write to
the userPassword attribute:
aci: (target="ldap:///cn=sync%20user,cn=config")
(targetattr="userPassword")(version 3.0;acl "aci1";allow (write,compare)
userdn=all;)
I figured this must be wrong since the target should contain the
replicated tree and the userdn should be the binddn for the sync user.
Correct me if I am wrong. I did try to use the above aci but also didn't
work.
Anyway I modified the aci such as:
[root@directory ~]# /usr/lib/mozldap/ldapsearch -b dc=example,dc=com -h
localhost -p 389 -D "cn=directory manager" -w - \(aci=*\) aci | grep -B
1 -C 1 Sync
Enter bind password:
aci: (target="ldap:///dc=example,dc=com")(targetattr="userPassword")
(version 3.0;acl "Sync Pass User";allow (write,compare)
userdn="ldap:///cn=sync%20user,cn=config";)"
Is the above ACI correct?
There must be something wrong since when I try to change the password of
a normal user I get the "Insufficient access rights" error:
[root@directory ~]# /usr/lib/mozldap/ldappasswd -v -Z
-P /etc/dirsrv/slapd-directory/cert8.db
-K /etc/dirsrv/slapd-directory/key3.db -D "cn=sync user,cn=config"
uid=pre_user1,ou=People,dc=example.com -w -
Enter bind password:
ldappasswd: started Tue Jan 12 11:46:28 2010
ldap_init( localhost, 389 )
ldaptool_getcertpath -- /etc/dirsrv/slapd-directory/cert8.db
ldaptool_getkeypath -- /etc/dirsrv/slapd-directory/key3.db
ldaptool_getmodpath -- (null)
ldaptool_getdonglefilename -- (null)
ldappasswd: Insufficient access
ldappasswd: additional info: Insufficient access rights
Any help/ideas would be highly appreciated!
Thanks
14 years, 2 months
Which Certificate to copy at 389-DS Client Machine?
by Ajeet S Raina
Hello Guys,
I have setup 389-DS Client and it does authenticate user login if I only use
:
TLS[ ]
ldap://
Base DN:<>
But if I mark it:
*TLS[*]
ldaps://<>
BaseDN:<>
*
it doesnt work !!
Seems like I have imported teh incorrect certificate
May I know which certificate I need to copy to client machine at
CLIENT MACHINE:
---------------------START------------------------
[root@localhost cacerts]# pwd
/etc/openldap/cacerts
[root@localhost cacerts]#
----------------------END---------------------------
389-DS SERVER MACHINE
---------------------START----------------------
.
All I can see is:
[code]
[root@389-ds admin-serv]# cd ..
[root@389-ds dirsrv]# cd slapd-389-ds/
[root@389-ds slapd-389-ds]# ls
adminserver.p12 certmap.conf dse.ldif.startOK noise.txt
pin.txt secmod.db
cacert.asc dse.ldif dse_original.ldif orig-cert8.db
pwdfile.txt slapd-collations.conf
cert8.db dse.ldif.bak key3.db orig-key3.db schema
[root@389-ds slapd-389-ds]# cd ..
[root@389-ds dirsrv]# cd admin-serv/
[root@389-ds admin-serv]# ls
adm.conf admserv.conf console.conf key3.db nss.conf secmod.db
admpw cert8.db httpd.conf local.conf password.conf
[root@389-ds admin-serv]#
[/code]
--------------------------END------------------------
Please suggest which certificate I need to copy to Client Machine
14 years, 2 months
389 and 636 both Port Open !!!
by Ajeet S Raina
I wonder how can I only open 1 port out of this two on my CentOS Machine:
[code]
[root@389-ds ~]# netstat -pant | grep "ns-slapd"
tcp 0 0 :::[B]389[/B]
:::* LISTEN 7956/ns-slapd
tcp 0 0 :::[B]636[/B]
:::* LISTEN 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.37.142:4806
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.37.142:4805
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.37.146:1699
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.47.177:4986
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.37.146:1698
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.37.146:1697
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.47.177:4985
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.37.146:1701
ESTABLISHED 7956/ns-slapd
tcp 0 0 ::ffff:10.209.37.91:636 ::ffff:10.209.37.142:4808
ESTABLISHED 7956/ns-slapd
[root@389-ds ~]#
[/code]
I have Fedora DS Installed and when I am trying to access through the client
ldap:// is working but not ldaps://
Pls Suggest
14 years, 2 months
Unable to access 389-Console Management from other windows Desktop !!!
by Ajeet S Raina
I have installed 389-Management Console and I can access the 389-DS server
from my Windows Desktop.
One of my Colleague is unable to access as it displays the screen of
Certificate acceptance and disappear suddenly.
I can view the certificate and able to login.
What could be the reason ? Is it Certificate Isue?
I have setup SSL for 389-DS.
14 years, 2 months
Windows PasswordSync 389 to ADS 2003, fail.
by Sergio A. Morales
Hi.
I read the list archives and i found several people with this problem:
Windows Sync works except password sync from 389 to ADS.
I have:
* ADS and 389 with SSL, all ok with this.
* No password complex policy en ADS
* Password Encryption in 389: CLEAR
* Windows Password Sync from AD to 389 works.
* I have cn=Administrator... in my replica agreement.
Full resync works and all account are created in Windows... But when i
change password from 389-console, there no change in ADServer, just
personal info like email or phone are in sync.
i have this log:
[12/Jan/2010:15:36:41 -0300] - Calling dirsync search request plugin
[12/Jan/2010:15:36:41 -0300] - Sending dirsync search request
[12/Jan/2010:15:36:41 -0300] NSMMReplicationPlugin -
agmt="cn=Again" (windows:389): Beginning linger on the connection
[12/Jan/2010:15:36:41 -0300] NSMMReplicationPlugin -
agmt="cn=Again" (windows:389): State: sending_updates ->
wait_for_changes
[12/Jan/2010:15:37:05 -0300] NSMMReplicationPlugin - changelog program -
_cl5GetDBFile: found DB object ef489a0 for database
2695e682-ff9d11de-beb8fde4-dd7504ff_4b4b955b000000010000.db4
[12/Jan/2010:15:37:05 -0300] NSMMReplicationPlugin - changelog program -
cl5GetOperationCount: found DB object ef489a0
[12/Jan/2010:15:37:41 -0300] NSMMReplicationPlugin -
agmt="cn=Again" (windows:389): Linger timeout has expired on the
connection
[12/Jan/2010:15:37:41 -0300] NSMMReplicationPlugin -
agmt="cn=Again" (windows:389): Disconnected from the consumer
I reinstall windows and 389 but nothing...
Someone has been solved this problem before? or Any ideas about how to
solve it?
Thank you
--
Sergio A. Morales <sergiomorales(a)archlinux.cl>
uSCI & CSRG Sysadmin
Archlinux Chile
14 years, 2 months
nss_ldap: failed to bind to LDAP server
by Ajeet S Raina
When I am trying to login as a user created under 389 DS server, it throws
error:
Jan 13 04:24:45 localhost sshd[3617]: nss_ldap: failed to bind to LDAP
server ldaps://10.209.37.91/: Can't contact LDAP server
Jan 13 04:24:45 localhost sshd[3617]: nss_ldap: reconnecting to LDAP server
(sleeping 64 seconds)...
Jan 13 04:24:47 localhost sshd[3631]: nss_ldap: failed to bind to LDAP
server ldaps://10.209.37.91/: Can't contact LDAP server
Jan 13 04:24:47 localhost sshd[3631]: nss_ldap: reconnecting to LDAP server
(sleeping 8 seconds)...
Jan 13 04:24:55 localhost sshd[3631]: nss_ldap: failed to bind to LDAP
server ldaps://10.209.37.91/: Can't contact LDAP server
Jan 13 04:24:55 localhost sshd[3631]: nss_ldap: reconnecting to LDAP server
(sleeping 16 seconds).
It was working earlier but no idea why its not working now.
All I attempted running:
authconfig --enableshadow --enablemd5 --enableldap --enableldapauth
--ldapserver=10.209.37.91 --ldapbasedn=dc=im,dc=sap,dc=com --enablecache
--enablemkhomedir --updateall
Manually I tried to do like:
Select LDAP
[*] TLS
URL: ldaps://<IP>
Base DN: dc=im,dc=sap,dc=com
But it dint work.
Pls Help
14 years, 2 months
Doubt regarding 389 Client Home Directory?
by Ajeet S Raina
Hello Guys,
All I have configured 389 Server and its working fine.
I can also run this command on client Machine as follows successfully:
ldapsearch -h 389-ds.sap.com -b "dc=im,dc=sap,dc=com" -L "objectclass=*"
And it does show me all the user statistics like this:
# extended LDIF
#
# LDAPv3
# base <dc=isst,dc=sapient,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# isst.sapient.com
dn: dc=im,dc=sap,dc=com
objectClass: top
objectClass: domain
dc: isst
# Directory Administrators, isst.sapient.com
dn: cn=Directory Administrators, dc=isst,dc=sapient,dc=com
objectClass: top
objectClass: groupofuniquenames
cn: Directory Administrators
uniqueMember: cn=Directory Manager
# Groups, im.sap.com
dn: ou=Groups, dc=im,dc=sap,dc=com
...
...
It means 389 Client is configured.
Now I added a User called meet on 389 DS Server.
I have provided:
Default Shell: /bin/bash
User ID: 610
GroupID:610
User name: snal
Now When I try logging into the server through :
username: meet
password:****
It says:
login as: snalamwar
snal(a)10.209.37.77's password:
Last login: Wed Jan 13 03:00:09 2010 from 10.209.37.146
Could not chdir to home directory /home/snal: No such file or directory
-bash-3.2$
Then I manually created a directory under /home as snal:
mkdir /home/snal
And Tried logging and this time it does login.
Is this process correct?
Do we need to create home directory manually.
Pls Suggest.
14 years, 2 months
389-ds on OpenSuse 11.2 and some problems
by Roland Schwingel
Hi...
First I have to say, that I am completely new to 389ds and (mostly) also
to LDAP.
But I want to setup an 389ds environment. I think I have managed to
compile 389ds
for OpenSuse 11.2. I am using OpenSuse as of the fact I am in a closed
network
with no access to the internet. So I have to use a distribution which
makes it
possible to install packages from the DVD. I find package management in
a closed environment with OS much easier as with FC or ubuntu which all
require internet access.
So, I believe I got everything compiled from sources on my OS, which was
more
complicated then I expected. I also walked thru to setup-ds-admin.pl.
ns-slapd and adminserver are running. From what I can see is my (empty)
ns-slapd is running fine.
I use the 389ds adminserver on top of an apache 2.2.14 and I got some
trouble with the adminserver. I had to tweak the LoadModules sections
in the adminserver's httpd.conf. They appear to belong to an older apache
version. I mostly removed all entries here.
Problem 1: Webpages
When I open the adminserver webpage (http://<myhost>:9830) and click on
"Fedora Administration Express" I get an (mostly) empty page justs
reading:
NMC_Status: 1
NMC_ErrType:
NMC_ErrInfo:
NMC_ErrDetail:
Does anybody know what this means and what might be broken here?
Problem 2: Adminserver console
Here I get a lot of errormessages when trying to click something in the
"Tasks" Tab. The only thing that appears to work is "Restart Server".
When I click eg. "Configure Admin Server" I get an alertpanel from java:
It is titled "Remote Request Error" and its content is:
URL: http://<myhost>:9830/admin-serv/tasks/Configuration/ServerSetup
Status: Failure
>From the adminserver's access.log I see that there is a HTTP POST to
this URL but it seems to succeed. Responsecode is 200.
There are also some repeatign suspicous entries in the error.log:
[client <client-ip-adress>] admserv_host_ip_check: ap_get_remote_host
could not resolve <client-ip-adress>
where <client-ip-adress> is the ip adress of the host where the console is
running on.
>From what I can see is my DNS setup ok. my client host is resolveable
forward
and also backward. Any ideas on this issues?
Thanks for your help,
Roland
14 years, 2 months
Re: [389-users] admin server under solaris not running
by Rich Megginson
Steffen Blume wrote:
> Rich Megginson wrote:
>
>> Steffen Blume wrote:
>>
>>> Hello,
>>>
>>> my admin server (apache/httpd.worker) is not starting under
>>> /OpenSolaris/ (/SunOS 5.11/).
>>> I added the error log below. Log level is debug. The only error msg is
>>> the last line from nss. I compiled 389 DS by myself.
>>> Versions:
>>> nss-3.12.4-with-nspr-4.8
>>> 389-ds-base-1.2.4
>>> mod_nss-1.0.8
>>> adminutil-1.1.8
>>> 389-admin-1.1.9
>>>
>>> --------------------------
>>> [Wed Jan 06 11:13:55 2010] [debug] mod_admserv.c(2419): Entering
>>> mod_admserv_post_config - pid is [6597] init count is [0]
>>> [Wed Jan 06 11:13:55 2010] [debug] mod_admserv.c(2248): Entering
>>> do_admserv_post_config - pid is [6597]
>>> [Wed Jan 06 11:13:55 2010] [debug] mod_admserv.c(2256): Entering
>>> do_admserv_post_config - init count is [1]
>>> [Wed Jan 06 11:13:55 2010] [debug] mod_admserv.c(2280): [6597] Cache
>>> expiration set to 600 seconds
>>> [Wed Jan 06 11:13:55 2010] [debug] mod_admserv.c(2383): Added
>>> StartConfigDs task entry
>>> [cn=startconfigds,cn=operation,cn=tasks,cn=admin-serv-ldap,cn=389
>>> administration server,cn=server
>>> group,cn=ldap.mydomain.de,ou=mydomain.de,o=netscaperoot:start_config_ds:]
>>>
>>> for user [LocalSuper]
>>> [Wed Jan 06 11:13:55 2010] [notice] Access Host filter is:
>>> *.mst.uni-hannover.de
>>> [Wed Jan 06 11:13:55 2010] [notice] Access Address filter is: *
>>> [Wed Jan 06 11:13:55 2010] [info] mod_unique_id: using ip addr
>>> xxx.xxx.xxx.xxx
>>> Assertion failure: SECSuccess == rv, at sslnonce.c:156
>>>
>>>
>> Do you have a core file for admin server?
>>
> No. It terminates without crashing.
>
>> If not, can you run the admin server using a debugger?
>>
> Just tried it with gdb. But gdb prints an internal error (and crashes):
>
> elfread.c:366: internal-error: sect_index_data not initialized
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) n
> elfread.c:366: internal-error: sect_index_data not initialized
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
>
> I looked at the nss source code, where the error occurs. Somehow the
> function NSS_RegisterShutdown is called before NSS is initialized and
> returns an error. I think this happens indirectly in mod_nss!?
>
Which compiler did you use? gcc or the free Sun compiler? If the
latter, I don't think gdb will work - you'll have to use the Sun
debugger (dbx?)
Both mod_nss and mod_admserv perform NSS initialization. mod_nss should
be loaded first, then mod_admserv.
>
>>> --------------------------
>>>
>>> Any advice?
>>>
>>> Regards,
>>> Steffen
>>>
>>>
>>>
>
>
14 years, 2 months