New Windows Active Directory Sync to 389 Directory Server
by Augustine Ike
Good Afternoon All,
How are you all doing today? Hope fine? I need
some help setting up 389 Directory Server Sync.
I have setup the server and it works. I have also tested imports from ldif
and it works. The server does fine as a
stand alone server.
The problem is in syncing with Windows Active Directory. I want to update
the 389 Directory Server with OU entries
from Active Directory. The agreement comes up sucessfully but I don't see
anything in the OU in the 389 Directory
Server. Based on the documentation, I have not setup SSL because I am under
the impression that it is for password sync only.
Can some one help me on this. I am going nuts.
Thanks
Augustine
13 years, 1 month
Announcing 389 Directory Server version 1.2.8.1 Testing
by Rich Megginson
The 389 Project team is pleased to announce the release of
389-ds-base-1.2.8.1. This release has fixes for bugs found in 1.2.8
testing and bugs from earlier releases.
Installation
yum install --enablerepo=updates-testing 389-ds
# or for EPEL
yum install --enablerepo=epel-testing 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 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. Each
update is broken down by package and platform. For example, if you are
using Fedora 13, and you have successfully installed or upgraded all of
the packages, and the console and etc. works, then go to the links below
for Fedora 13 and provide feedback.
* EL-5 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.el5
* Fedora 13 -
https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.fc13
* Fedora 14 -
https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.fc14
* Fedora 15 -
https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.fc15
scroll down to the bottom of the page, and click on the Add a comment >>
link
* select one of the Works for me or Does not work radio buttons, add
text, and click on the Add Comment button
If you are using a build on another platform, 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
13 years, 1 month
StartTLS with F14, 389-console and system-config-authentication
by Bob McKay
I'm trying to do set up authentication between fedora 14 client and server
using ldap passwords. I seem to be having a problem getting the server to
accept startTLS. It has all been set up with 389-console and
system-config-authentication.
In more detail, I set up the client using system-config-authentication, to
use LDAP for the user account authentication, TLS to encrypt connections,
and LDAP passwords. I set the LDAP server to ldap://<server name>. All this
seems to be working OK, on the server (wireshark) I can see the initial ldap
handshake on port 389, as expected. The problem seems to start at the next
stage. I see a tcp packet to port 389 from the client, protocol LDAP, Info
extendedReq(1) LDAP_START_TLS_OID, which I assume is the request packet from
the client to start the TLS handshake. I see a TCP ack from the server, but
this is immediately followed by a protocol LDAP message from the server to
the client, extendedResp(1) (unsupported extended operation). I assume this
is a failure message. However the client replies with an SSLv2 Client Hello.
There is never an SSL response,
On the client, I see in the logs
ssd[be[LDAP]]: Could not start TLS encryption. unsupported extended
operation
which I assume confirms that the attempt to start up TLS failed.
In the server dirsrv access log, I see:
[08/Apr/2011:16:40:46 +0900] conn=12 fd=64 slot=64 connection from
192.168.1.7 to 192.168.1.192
[08/Apr/2011:16:40:46 +0900] conn=12 op=0 EXT oid="1.3.6.1.4.1.1466.20037"
[08/Apr/2011:16:40:46 +0900] conn=12 op=0 RESULT err=2 tag=120 nentries=0
etime=0
[08/Apr/2011:16:40:46 +0900] conn=12 op=-1 fd=64 closed error 71 (Protocol
error) - B1
and in the error log (logging verbosity turned up a bit) I see
[08/Apr/2011:17:13:22 +0900] - new connection on 64
[08/Apr/2011:17:13:22 +0900] - activity on 64r
[08/Apr/2011:17:13:22 +0900] - read activity on 64
[08/Apr/2011:17:13:22 +0900] - conn 16 activity level = 0
[08/Apr/2011:17:13:22 +0900] - listener got signaled
[08/Apr/2011:17:13:22 +0900] - flush_ber() wrote 44 bytes to socket 64
[08/Apr/2011:17:13:22 +0900] - activity on 64r
[08/Apr/2011:17:13:22 +0900] - read activity on 64
[08/Apr/2011:17:13:22 +0900] - conn=16 received a non-LDAP message (tag
0x80, expected 0x30)
[08/Apr/2011:17:13:22 +0900] - conn 16 leaving turbo mode due to 3
[08/Apr/2011:17:13:22 +0900] - listener got signaled
All this seems to suggest that either I don't have startTLS built into my
installation of 389, or I'm somehow failing to enable it. However I can't
see any plugin in yum that would help, and the only place I can see (at
least in 389-console) that looks like it could affect this is the Domain
name "Secure connection" checkbox. However I've tried toggling this and I
see exactly the same behaviour either way (I'm guessing that the checkbox
actually enables SSL support on port 636, but the documentation isn't too
clear on this).
One possibility, that I'm not too sure how to check, is that the
(self-signed) CA certificate or the server certificate might be bad. However
they look fine on dumping, and both appear to be installed in the server.
And hopefully, I would have got rather more informative log messages in this
case. I'm not too sure how to test this locally on the server, any pointers
on how to do this would be great.
Any help anyone can give on this would be _hugely_ appreciated - I am now
three days in on what looked like it was supposed to be a straightforward
install, with no real progress, and getting further behind on other urgent
stuff. Urrgggg.
System:
Client and server:
F14, 2.6.35.11-83.fc14.x86_64 kernel
Server:
slapd 2.4.23
Client:
sssd 64-bit 1.5.4-1.fc14
Best Wishes
Bob
13 years, 1 month
Can't adjust error log level - 389 DS 1.2.7.5
by Barry Sitompul
Hi All,
I'm testing DS upgrade from 1.2.5 to 1.2.7.5 on RHEL 5
I'm getting a lot of new error messages in the 1.2.7.5 error log (default
logging config). These errors do not appear on the 1.2.5 (default logging
config as well) when doing an LDAP search and mod to a user on a certain
tree:
"NSACLPlugin - acllas__client_match_URL: url [ldap:///ou=something,o=the
university of queensland,c=au??sub?(objectclass=*)] scope is subtree but
dn [ou=something,o=the university of queensland,c=au] is not a suffix of
[uid=modadmin,ou=privileged,o=the university of queensland,c=au]"
It's saying that the tree that I am searching is not a suffix of the user
DN I use to bind. It looks more like a warning because the operation
completed successfully, located the user and modified the attributes. Is
this just a new feature that can be turned off?
Is there anything else I can do to disable these error messages? I've
tried to adjust the error log level from the console as per the RedHat
documentation for DS 8.2 but I couldn't find any functions to do so on
config tab->error log. I have also added nsslapd-errorlog-level: 256 to
the dse.ldif but it didn't do anything.
Any help is much appreciated!
Thanks,
Baz
13 years, 1 month
map value of ServerAdminID for key as_uid did not map to value...
by Stephen Ingram
I'm trying to register an ipa v2 directory server with
register-ds-admin.pl so that I may use the ds-console to view the
directory. As I see that the ipa portion of the directory is meant to
be managed by ipa, I don't intend on touching that part of the tree.
However, it would be really nice to be able to view the directory
configuration and maybe make configuration changes (if allowed) using
the 389-ds-console. I found an earlier post about automating this
process, but it apparently dealt with only version 1.
Running register-ds-admin.pl, I have successfully created an admin
server as well as another directory to store the configuration into.
However, when I try to register the ipa directory server, I get the error:
The map value 'ServerAdminID' for key 'as_uid' did not map to a value
in any of the given information files.
I see this error referenced in earlier 389-ds bug reports, but it is
supposed to have already been fixed. I'm using version 1.2.8-0.3.a3 on
Fedora 14. Should I file another bug report?
Steve
13 years, 1 month
Re: [389-users] admin server fails to start with PSET failure: Failed to create PSET handle
by Angel Bosch Mora
----- Missatge original -----
> On 04/07/2011 04:37 AM, Angel Bosch Mora wrote:
> > hi,
> >
> > im having problems starting admin server. i can see just this line
> > on log:
> >
> > [Thu Apr 07 12:26:13 2011] [crit] host_ip_init(): PSET failure:
> > Failed to create PSET handle (pset error = )
> >
> > not sure if is related, but we had an accident that changed
> > permissions on some files (recursive chmod on wrong directory). main
> > instance seems to work ok, so im a bit lost here.
> What platform? What version of 389-ds-base and 389-admin?
> ls -al /etc/dirsrv/admin-serv
sorry, i was a bit nervous this morning :)
# lsb_release -a
LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.5 (Final)
Release: 5.5
Codename: Final
# rpm -qa | grep 389
389-admin-1.1.11-1.el5
389-ds-console-doc-1.2.3-1.el5
389-adminutil-1.1.8-4.el5
389-dsgw-1.1.5-1.el5
389-admin-console-doc-1.1.5-1.el5
389-admin-console-1.1.5-1.el5
389-ds-1.2.1-1.el5
389-ds-base-1.2.6.1-2.el5
389-ds-console-1.2.3-1.el5
389-console-1.1.4-1.el5
# ls -al /etc/dirsrv/admin-serv/
total 176
drwxrwx--- 2 root duser 4096 Nov 5 18:21 .
drwxrwxr-x 7 root duser 4096 Nov 5 18:21 ..
-rw-rw---- 1 root duser 544 Nov 5 18:21 adm.conf
-rw-rw---- 1 root duser 40 Nov 5 18:21 admpw
-rw-rw---- 1 root duser 3924 Aug 26 2010 admserv.conf
-rw-rw---- 1 root duser 65536 Mar 15 12:44 cert8.db
-rw-rw---- 1 root duser 4469 Nov 5 18:21 console.conf
-rw-rw---- 1 root duser 26827 Nov 11 12:23 httpd.conf
-rw-rw---- 1 root duser 16384 Mar 15 12:44 key3.db
-rw-rw---- 1 root duser 9093 Mar 18 10:21 local.conf
-rw-rw---- 1 root duser 4502 Aug 26 2010 nss.conf
-rw-rw---- 1 root duser 16384 Nov 5 18:21 secmod.db
this duser is the user/grup created before installation and used for setup-ds.pl
if you need further info, pls just ask.
thnaks,
abosch
13 years, 1 month
admin server fails to start with PSET failure: Failed to create PSET handle
by Angel Bosch Mora
hi,
im having problems starting admin server. i can see just this line on log:
[Thu Apr 07 12:26:13 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = )
not sure if is related, but we had an accident that changed permissions on some files (recursive chmod on wrong directory). main instance seems to work ok, so im a bit lost here.
regards,
abosch
13 years, 1 month
Windows Sync and UserAccountControl
by Diego Woitasen
I setup Windows Sync between 389DS and W2008r2. Worked fine. Now we had to
downgrade the Windows server to 2003 and I don't know why I can't setup the
Sync again. The only error that I see in the 389-console (there is nothing
in the error log) is "operations error", after creating the agreement.
I sniffed the traffic between 389DS and W2003 and I saw an objectClass
violation when 389 tried to add the userAccountControl atttr to a group. The
group is created anyway.
I've searched in the web and it looks like userAccountControl is only for
users, not for groups. Looking at the Windows Sync code it looks like 389 DS
always add that attribute for both.
Regards,
Diego
--
Diego Woitasen
13 years, 1 month
389-console fonts issue
by Orion Poplawski
I've got a strange issue that I find annoying. My desktop machine is running
Fedora 14. If I ssh to my 389 server and run 389-console there, the fonts are
messed up (see attached snapshot). Everything is fine though if I run the
console from my desktop. Also, this used to be fine, but some update long ago
seems to have caused it.
Any thoughts or ideas on how to debug? I ran a diff of -D 9 -f console.log
output from the two and no smoking guns there.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 2 months
A lot of sessions in LDAP 389
by Allan Hougham
Hi,
I have a problem with sessions in LDAP 389 master and slave, this servers have accumulative sessions, I can see in logs:
[root@zblhp36 ~]# netstat -na |grep 389 |wc -l
795
795 sessions and later the server is down, I have restart the server and later this is ok with less sessions:
[root@zblhp36 ~]# netstat -na |grep 389 |wc -l
795
[root@zblhp36 ~]# service dirsrv restart
Shutting down dirsrv:
zblhp36... [ OK ]
Starting dirsrv:
zblhp36...
[root@zblhp36 ~]# netstat -na |grep 389 |wc -l
12
In this time, both servers work fine, but a week or 10 days this problem is again with a lot a sessions
What parameter I could to change?
Thanks!
Allan
13 years, 2 months
