Windows Console Quit Working
by Glenn
Sorry to be such a pest, but now I have another problem. The Windows
console, which worked fine on my computer for two years, suddenly quit. I
installed the latest console, but it does the same thing. It starts up fine
and displays the login window. After I enter login credentials, the DOS
window hangs. I'm copying the contents of the DOS window below. Any ideas
appreciated. We are using Fedora Directory 1.0.4 on RHEL4. Thanks. -G.
C:\Program Files\Fedora Identity Management Console>echo off
C:\Program Files\Fedora Identity Management Console>"java" "-
Djava.library.path=
." -cp "./jss4.jar;./ldapjdk.jar;./idm-console-base.jar;./idm-console-
mcc.jar;./
idm-console-mcc_en.jar;./idm-console-nmclf.jar;./idm-console-
nmclf_en.jar;./fedo
ra-idm-console_en.jar" -Djava.util.prefs.systemRoot=/.fedora-idm-console -
Djava.
util.prefs.userRoot=/.fedora-idm-console
com.netscape.management.client.console.
Console
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Program
Files\Fedo
ra Identity Management Console\jss4.dll: The specified procedure could not be
fo
und
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.mozilla.jss.CryptoManager.loadNativeLibraries
(CryptoManager.java:
1339)
at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:827)
at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:800)
at com.netscape.management.client.util.UtilConsoleGlobals.initJSS
(Unknow
n Source)
at com.netscape.management.client.comm.HttpsChannel.<clinit>(Unknown
Sou
rce)
at com.netscape.management.client.comm.HttpManager.createChannel
(Unknown
Source)
at com.netscape.management.client.comm.CommManager.send(Unknown
Source)
at com.netscape.management.client.comm.CommManager.send(Unknown
Source)
at com.netscape.management.client.comm.HttpManager.get(Unknown Source)
at com.netscape.management.client.console.Console.invoke_task(Unknown
So
urce)
at com.netscape.management.client.console.Console.authenticate_user
(Unkn
own Source)
at com.netscape.management.client.console.Console.<init>(Unknown
Source)
at com.netscape.management.client.console.Console.main(Unknown Source)
14 years, 5 months
Perl/python script to sync with AD
by Prashanth Sundaram
Dear All,
I finally got the 389-ds working with PAM-PTA and everything looks fine so
far. I am investigating on scripting the AD sync using
perl/python/ldapscripts(shell). Anybody has any advice on the choice. I see
perl¹s Net:LDAP is pretty comprehensive with easy to use functions, but
just in case if your opinion differs. I have a Perl script which partially
does the job and wouldn't mind sharing if you want to take a peep.
requirements:
1. Sync one-way from AD --> LDAP with only posix attributes.
2. Disable/delete accounts in ldap if disabled/deleted in AD.
3. Sync Groups and its members.
PS: I am a newbie with scripting.
Thanks,
Prashanth
14 years, 5 months
valid password characters?
by Derek Alexander
Hi,
Just got this error message back from FDS.
"LDAP: error code 19 - The value is not 7-bit clean"
Looks like it was due to the user putting the following character in their password: '§'
What are the constraints on valid characters in passwords?
Have tried searching but don't see anything documented on the password policy or syntax pages.
Cheers,
Derek
Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm
14 years, 5 months
Administration URL
by Jesster Leight
Where i can find Administration URL for 389-console ?
After configuration with script /usr/sbin/setup-ds-admin.pl, nothing
information about Administration URL :
-----
Are you ready to set up your servers? [yes]:
Creating directory server . . .
Your new DS instance 'satellite' was successfully created.
Creating the configuration directory server . . .
Beginning Admin Server creation . . .
Creating Admin Server files and directories . . .
Updating adm.conf . . .
Updating admpw . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Updating the configuration for the httpd engine . . .
Starting admin server . . .
The admin server was successfully started.
Admin server was successfully created, configured, and started.
Exiting . . .
Log file is '/tmp/setup5Y5efv.log'
14 years, 5 months
DSGW error with Macintosh Safari
by Glenn
We are using Fedora Directory 1.0.4 with Red Hat EL4. We use the Directory
Gateway, and it works fine with Windows-based browers including Internet
Explorer and Firefox. However, when we try to use Safari on a Macintosh
computer, we get an error headed by the ominous "Problem". The error message
is, "The charset is not supported (ISO_8859-1)". This appears whenever we
try to authenticate or search the directory.
The Googling I've done so far indicates that Safari might not be sending form
data to the directory server whenever data is entered into a form, such as
authentication credentials or search terms. We do not have a java expert in-
house, so I'm hoping there is some simple tweak I can do to fix this. The
Mac used for testing is a MacMini 1.1 running Mac OSX 10.4.11 and Safari 3.2.1
(4525.27.1). Thanks. -G.
14 years, 5 months
Query blocking server
by Juan Asensio Sánchez
Hi
Samba is making a query to our 389 DS (v. 1.2.2, and too older
versions) that makes the servers freeze. The server is running, and
accepting connections, although the next queries are not processed
until the Samba query is returned. This Samba query takes a long time
to be returned, because it is searching all databases and all objects
in the directory (more than 20000). The filter is
"(&(uid=*)(objectClass=sambaSamAccount))". This query is done when
executing the command "net user" from a Windows or Linux machine. This
queries are executed manually, and intentionally, but should not make
the server freeze. Why is this happening? Is there any option to avoid
this?
Regards.
14 years, 5 months
Announcing testing release of 389 1.2.4
by Rich Megginson
The 389 team is pleased to announce that the 389 Directory Server
version 1.2.4 is available for testing. The packages are available from
the testing repositories, not the official release repositories yet. We
are seeking feedback. There is one new package available for testing:
* 389-ds-base-1.2.4
NOTE: The best way to provide feedback is through the Fedora Updates
System. If you have a Fedora Updates account, go here:
***** Your Feedback is Important! *****
The best way to provide feedback is via the Fedora Update system. If
you have an account, go here:
* https://admin.fedoraproject.org/updates/F10/FEDORA-2009-11023
* OR
* https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10901
* 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)redhat.com.
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
Instructions for installing these from the testing repositories:
yum install --enablerepo=updates-testing 389-ds # Fedora new install
yum upgrade --enablerepo=updates-testing 389-ds-base # Fedora upgrade
or EL5
yum install --enablerepo=dirsrv-testing --enablerepo=idmcommon-testing
389-ds # new install
yum upgrade --enablerepo=dirsrv-testing --enablerepo=idmcommon-testing
389-ds-base # upgrade
See http://port389.org/wiki/Download for more
information about setting up yum access.
Release Notes: http://port389.org/wiki/Release_Notes
Install Guide: http://port389.org/wiki/Install_Guide
Download: http://port389.org/wiki/Download
=== Notes ===
NOTE: If using the FC6 (EL5) packages, _you must update your yum repo
files_ - the URLs have changed. See
http://port389.org/wiki/Download for more information.
NOTE: Fedora versions below 10 are no longer supported. If you are
running Fedora 9 or earlier, you should upgrade.
NOTE: This release is branded as '''389'''. All of the RPMs have been
marked as obsoleting their Fedora DS counterparts. When upgrading via
yum, you must use yum '''upgrade''' (not update) so that the obsoletes
will be processed.
NOTE: If you are using the console, after installing the updates, you
must run '''setup-ds-admin.pl -u''' to refresh your console and admin
server configuration with the new version information. 1.2.4 fixes some
bugs related to update - it will remove old Fedora servers from the
console, and will preserve TLS/SSL configuration. See the buglist below.
NOTE: '''389-console''' is the command to run the console. This
replaces fedora-idm-console.
=== New features ===
* Support for Salted MD5 (SMD5) passwords - primarily for migration - do
not use SMD5 for new passwords - use SSHA256 and higher
=== Bugs Fixed ===
This release contains a couple of bug fixes. The complete list of bugs
fixed is found at the link below. Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.4 release -
[https://bugzilla.redhat.com/showdependencytree.cgi?id=531879&hide_resolved=0
https://bugzilla.redhat.com/showdependencytree.cgi?id=531879&hide_resolved=0]
** [https://bugzilla.redhat.com/show_bug.cgi?id=221905 221905] Add SMD5
password support
** [https://bugzilla.redhat.com/show_bug.cgi?id=529258 529258] upgrade
should remove duplicate and obsolete schema from 99user.ldif
14 years, 5 months
repl_set_mtn_referrals: could not set referrals for replica
by Juan Asensio Sánchez
Hi
We are having problems with replication. We have four master servers
replicating one database (database 1), and two other servers in other
building that are masters of other database (database 2). Replication
between the databases of the others are in hub mode (server1 of
building1 with server1 of building1, and server2 of building1 with
server2 of building2; server3 and server4 of building1 only have
agreements with server1 and server2 of building1). Yesterday we had to
remove the replica of server4 of database 1. Next, we did ree-enable
the replica and the replication agreements, but the replica was
enabled with a different id than before. Now, we have this error on
all servers, although replication is working fine:
[16/Oct/2009:12:44:39 +0200] NSMMReplicationPlugin -
repl_set_mtn_referrals: could not set referrals for replica
dc=domain,dc=local: 1
(dc=domain,dc=local is the prefix that owns the database 1). I don't
know if this error is critical, but i don't like to see errors in the
log (call me fool if you want). I have read some posts:
- http://blogs.sun.com/marcos/entry/on_cleanruv
- http://blogs.sun.com/piotr/entry/how_to_clean_ruv_s
All about Sun, but i am not sure if this will work, or if it is
dangerous because it says that the solution is unsupported and
irreversible. How can I get rid of this message? is it critical?
Regards and thanks in advance.
14 years, 5 months
Admin-console doesn't work after upgrade
by Jens Ådne Rydland
Hi,
recently our LDAP server (CentOS 5.4) got upgraded, so we no longer have
the command fedora-idm-console, but instead have gotten 389-console. The
LDAP service it self works flawlessly, but when trying to open the admin
console it fails with
"netscape.ldap.LDAPException: error result (32); No such object"
Running "service dirsrv-admin status" returns that the admin server is
running, and running 389-console with -D indicates that the server
indeed replies.
So, is there some extra configuration needed after upgrading, such as
running setup-ds-admin.pl again? If so, where can I look up the
information provided on the initial setup?
This is using 389-ds version 1.1.3, CentOS 5.4, Java 1.6.0 (OpenJDK
Runtime Environment (build 1.6.0-b09))
--
mvh Jens Ådne Rydland
14 years, 5 months
AD2008 on 64 bit windows, 389 Directory Server passwords...
by Anne (juniper) Cross
I'm trying to sync passwords from 389 to Active Directory.
If we import users from AD, then try to change their passwords, the
replication locks up.
If we create the users on 389, and sync them back to AD, the password
field passed back is blank in Windows.
Passsync isn't going to work because we're running 64bit Windows, so we
can't sync the passwords *from* AD. I got this working earlier, but
that was with FDS in a test instance several months ago, and I didn't
write down what I did. (And I am kicking myself over that.) We can
live without people changing their passwords on AD as long as we *can*
sync passwords down from 389.
The replication manager account on AD has full Directory Admin privs, so
it *does* have the ability to update passwords.
What am I missing? Our logs are showing us a lot of things that are not
helpful; I will be happy to attach further logs if people can tell me
what to look for, but we've been trying this for two days now, and we're
not any closer than we were when we started.
--
,___,
{o,o} Anne "Juniper" Cross
(___) Senior Linux Systems Engineer and Extropic Crusader
-"-"-- Information Technology, ITA Software
/^^^
14 years, 5 months
