limit account to see only certain values
by Karoly Czovek
Hi guys,
I want to limit a few technical user, to see only certain attributes. but it fails.
1) added the userc cn=emailServerLookup under ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
2) set up an ACL named emailServer on the top of my dc=example,dc=com , added that user , limited the reachable attributes to mail*
Do i missed anything?
Once i run a lookup, i get back every attributes, not just the ones what i gave access to, even the passwords.
I don't want do disable anonymous lookup while this one is not working. Any idea?
--
Karoly CZOVEK
Global Systems Administrator
MoveOne IT Department
Eastern Europe - Balkans - CIS& Central Asia - Middle East& Africa -
Asia Pacific
phone: +36 1 266 0181 - ext.6710
mobile: +36 70 708 9953
skype: mo_karoly.czovek
email: karoly.czovek(a)moveoneinc.com
web: http://www.moveoneinc.com
12 years, 6 months
Announcing 389 Directory Server version 1.2.9.6 Testing
by Rich Megginson
The 389 Project team is pleased to announce the release of
389-ds-base-1.2.9.6. This release has fixes for bugs found in 1.2.9
testing and bugs from earlier releases.
NEW: EL6 support
Beginning with RHEL 6.1, the 389-ds-base package is included in the base
OS. It is the same as the upstream, except that it has no replication
nor windows sync functionality. That has been split off into a new
channel - Enterprise Identity Replication - and a new package -
ds-replication. Therefore, the 389-ds-base package can no longer be
provided via EPEL, due to RHEL/EPEL packaging restrictions.
However, the 389 Project will still make the full 389-ds-base package,
including replication/winsync, available via
http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. See
http://directory.fedoraproject.org/wiki/Download for more information.
Installation
yum install --enablerepo=updates-testing 389-ds
# or for EPEL
yum install --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds
setup-ds-admin.pl
Upgrade
yum upgrade --enablerepo=updates-testing 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
# or for EPEL
yum upgrade --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
setup-ds-admin.pl -u
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
* Go to https://admin.fedoraproject.org/updates
* In the Search box in the upper right hand corner, type in the name of
the package
* In the list, find the version and release you are using (if you're not
sure, use rpm -qi <package name> on your system) and click on the release
* On the page for the update, scroll down to "Add a comment" and provide
your input
Or just send us an email to 389-users(a)lists.fedoraproject.org
Reporting Bugs
If you find a bug, or would like to see a new feature, you can enter it
here - https://bugzilla.redhat.com/enter_bug.cgi?product=389
More Information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
12 years, 6 months
add inetuser objectclass on replication
by Vasil Mikhalenya
Hi all,
DS is replicated from AD, I want memberOf enabled for all users ( new
users also ) but memberOf plugin requires inetuser objectclass.
How can I add inetuser objectclass to any user on/after replication.
There is any other way do it?
Thank you.
--
Best regards,
Vasil Mikhalenya
12 years, 7 months
Fwd: 389 v1.2.9.8 freeze/deadlock
by Ivanov Andrey (M.)
Hi,
i've tried to install the 1.2.9.8 testing version in our production
environment but there is a regular freeze/deadlock after a particular
search.
It is a search sent by outlook 2003 (you type the name of the person
and then click "Check the name" button that generates an LDAP
request). The person does not exist in the given subtree, here is the
corresponding connection in the logs :
[01/Sep/2011:13:42:34 +0200] conn=938 fd=129 slot=129 connection from
x.x.x.x to y.y.y.y
[01/Sep/2011:13:42:34 +0200] conn=938 op=0 BIND dn="" method=128 version=3
[01/Sep/2011:13:42:34 +0200] conn=938 op=0 RESULT err=0 tag=97
nentries=0 etime=0.000000 dn=""
[01/Sep/2011:13:42:34 +0200] conn=938 op=1 SRCH
base="ou=etudiants,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu"
scope=2 filter="(&(mail=*)(|(mail=le tallec*)(cn=le tallec*)(sn=le
tallec*)(givenName=le tallec*)(displayName=le tallec*)))" attrs="cn cn
mail roleOccupant display-name displayName sn sn co o o givenName
legacyexchangedn objectClass uid mailnickname title company
physicalDeliveryOfficeName telephoneNumber"
[01/Sep/2011:13:42:34 +0200] conn=938 op=1 SORT cn (1)
<end of access log, nothing in error log, server freezes>
The problem is reproducible each time, here is the interesting part of
the gdb trace :
Thread 42 (Thread 0x42201940 (LWP 25005)):
#0 0x00000038644cd722 in select () from /lib64/libc.so.6
No symbol table info available.
#1 0x00002b8ffb1bf959 in DS_Sleep () from
/Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#2 0x00002b900104e51e in deadlock_threadmain () from
/Local/dirsrv/lib/dirsrv/plugins/libback-ldbm.so
No symbol table info available.
#3 0x00000038670284ad in ?? () from /usr/lib64/libnspr4.so
No symbol table info available.
#4 0x000000386500673d in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5 0x00000038644d44bd in clone () from /lib64/libc.so.6
No symbol table info available.
...
Thread 24 (Thread 0x4d613940 (LWP 25023)):
#0 0x000000386500d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x0000003865008e50 in _L_lock_1233 () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x0000003865008dd3 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x0000003867022ec9 in PR_Lock () from /usr/lib64/libnspr4.so
No symbol table info available.
#4 0x00002b8ffb18b308 in slapi_pblock_get () from
/Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#5 0x00002b8ffff8ac54 in DS_LASIpGetter () from
/Local/dirsrv/lib/dirsrv/plugins/libacl-plugin.so
No symbol table info available.
#6 0x00002b90001bfb08 in ACL_GetAttribute () from
/Local/dirsrv/lib/dirsrv/libns-dshttpd.so.0
No symbol table info available.
#7 0x00002b90001be979 in LASIpEval () from
/Local/dirsrv/lib/dirsrv/libns-dshttpd.so.0
No symbol table info available.
#8 0x00002b90001c0c30 in ACLEvalAce(NSErr_s*, ACLEvalHandle*,
ACLExprHandle*, unsigned long*, PListStruct_s**, PListStruct_s*) ()
from /Local/dirsrv/lib/dirsrv/libns-dshttpd.so.0
No symbol table info available.
#9 0x00002b90001c11ce in ACL_INTEvalTestRights(NSErr_s*,
ACLEvalHandle*, char**, char**, char**, char**, char**, int*, unsigned
long*) () from /Local/dirsrv/lib/dirsrv/libns-dshttpd.so.0
No symbol table info available.
#10 0x00002b90001c1956 in ACL_EvalTestRights () from
/Local/dirsrv/lib/dirsrv/libns-dshttpd.so.0
No symbol table info available.
#11 0x00002b8ffff7e223 in acl__TestRights () from
/Local/dirsrv/lib/dirsrv/plugins/libacl-plugin.so
No symbol table info available.
#12 0x00002b8ffff813d6 in acl_access_allowed () from
/Local/dirsrv/lib/dirsrv/plugins/libacl-plugin.so
No symbol table info available.
#13 0x00002b8ffff959a4 in acl_access_allowed_main () from
/Local/dirsrv/lib/dirsrv/plugins/libacl-plugin.so
No symbol table info available.
#14 0x00002b8ffb192a61 in plugin_call_acl_plugin () from
/Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#15 0x00002b8ffb16247d in slapi_vattr_filter_test_ext_internal () from
/Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#16 0x00002b8ffb1622b8 in slapi_vattr_filter_test_ext_internal () from
/Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#17 0x00002b8ffb162544 in slapi_vattr_filter_test_ext () from
/Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#18 0x00002b900109010f in ldbm_back_next_search_entry_ext () from
/Local/dirsrv/lib/dirsrv/plugins/libback-ldbm.so
No symbol table info available.
#19 0x00002b8ffb1868d1 in iterate () from /Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#20 0x00002b8ffb187ce8 in op_shared_search () from
/Local/dirsrv/lib/dirsrv/libslapd.so.0
No symbol table info available.
#21 0x0000000000429c78 in do_search ()
No symbol table info available.
#22 0x000000000041472f in connection_threadmain ()
No symbol table info available.
#23 0x00000038670284ad in ?? () from /usr/lib64/libnspr4.so
No symbol table info available.
#24 0x000000386500673d in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#25 0x00000038644d44bd in clone () from /lib64/libc.so.6
No symbol table info available.
I'll try to install the debug symbols and reproduce the stack trace
with symbol table after i roll back to our previous production version
(1.2.8.3)
@+
12 years, 7 months
Failed to install a local copy of 389-ds-1.2.6.jar
by Jim Hilton
Hi,
When I open the Directory Server console on a fresh install of 389-ds I
get the following message:
"Failed to install a local copy of 389-ds-1.2.6.jar or one of its
supporting files"
I have installed 389-ds via yum on a fresh Fedora 15 server and it looks
like 389-ds-console is 1.2.5 but needs to be 1.2.6. The directory
/usr/share/dirsrv/html/java contains the 1.2.5.jar but not the
1.2.6.jar. The following packages were installed via "yum install 389-ds"
389-ds-console-1.2.5-1.fc15.noarch
389-ds-console-doc-1.2.5-1.fc15.noarch
389-ds-base-libs-1.2.9.6-1.fc15.x86_64
389-console-1.1.4-2.fc15.noarch
389-ds-base-1.2.9.6-1.fc15.x86_64
389-admin-console-1.1.7-2.fc15.noarch
389-dsgw-1.1.6-2.fc15.x86_64
389-adminutil-1.1.13-2.fc15.x86_64
389-admin-1.1.16-1.fc15.x86_64
389-admin-console-doc-1.1.7-2.fc15.noarch
389-ds-1.2.2-1.fc15.noarch
I copied 389-ds-1.2.5.jar to 389-ds-1.2.6.jar as a test and that allowed
me to login, but I suspect that's not the solution and may cause other
issues?
Thanks.
Jim.
12 years, 7 months
Re: [389-users] Setting up multi master replication error 81
by David Hoskinson
I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here?
[root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*"
version: 1
dn:
objectClass: top
namingContexts: dc=stag,dc=cle,dc=us
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
supportedSASLMechanisms: DIGEST-MD5
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636
dataversion: 020110831163410
netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389
David Hoskinson | DATATRAK International
Systems Engineer
Mayfield Heights, Ohio, USA
+1.440.443.0082 x 124 (p) | +1.216.280.5457 (m)
david.hoskinson(a)datatrak.net<mailto:david.hoskinson@datatrak.net> | www.datatrak.net<http://www.datatrak.net/>
12 years, 7 months