Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 3 months
changelog
by Denise Cosso
Hi,
How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Thanks,
Denise
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
dn: cn=changelog5,cn=config
[...]
nsslapd-encryptionalgorithm: AES
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:34
On 06/04/2013 01:26 PM, Denise Cosso
wrote:
Hi, Rich
CentOS release 6.3 (Final)
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-ds-1.2.2-1.el6.noarch
389-dsgw-1.1.10-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-1.2.10.2-20.el6_3.x86_64
As far as replication goes - you will need to use a security layer
(SSL, TLS, or GSSAPI) to protect the clear text password on the wire
As far as encrypting it in the changelog - not sure
Denise
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
server project."
<389-users(a)lists.fedoraproject.org>
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
On
06/04/2013 12:39 PM, Denise Cosso wrote:
Hi,
Description of problem:
When a userPassword is changed in a server with changelog, the hashed password
is logged and also a cleartext pseudo-attribute version. It looks like this:
change::
replace: userPassword
userPassword: {SHA256}vqtiN2LHdrEUOJUKu+IBVqAVFsAlvFw+11kD/Q==
-
replace: unhashed#user#password
unhashed#user#password: secret12
This unhashed version is used in winsync where the cleartext version of the
password must be written to the AD.
Now if the DS is involved in replication with another DS, the change will be
replayed exactly as it is logged to the other DS replicas, including the
cleartext pseudo-attribute password.
What platform? What version of 389-ds-base are you
using?
thanks,
Denise
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
8 years, 7 months
389 Master - Master Replication
by Santos Ramirez
Good Morning,
We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated.
Santos U. Ramirez
Linux Systems Administrator
National DCP, LLC
150 Depot Street
Bellingham, Ma. 02019
Phone: 508-422-3089
Fax: 508-422-3866
Santos.Ramirez(a)natdcp.com<mailto:Santos.Ramirez@natdcp.com>
This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.
9 years, 2 months
FW: fresh replica reports "reloading ruv failed " just after successfull initialization
by Jovan.VUKOTIC＠sungard.com
Hi,
I would like to link the issue I reported on Saturday with the bug 723937 filed some two years ago.
There, just as in my case, dn/entry cache entries have been reported prior to the initialization of master replica.
I repeated the replication configuration today, where the multi-master replica that was initialized by other replica having only one entry in userRoot datase prior the initialization( root object)
First, two entries were found, then 5... and then 918 (matches the number of entries from the master database)
24/Jun/2013:08:16:03 -0400) - entrycache_clear_int: there are still 2 entries in the entry cache.
[24/Jun/2013:08:16:03 -0400) - dncache_clear_int: there are still 2 dn's in the dn cache. :/
[24/Jun/2013:08:16:03 -0400) - WARNNG Import is running with nsslapd-db-private-import-mem on: No other process is allowed to access the database
[24/Jun/2013:08:16:07 -04001 - import userRoot: Workers finished: cleaning p...
[24/Jun/2013:08:16:07 -0400) - import userRoot: Workers cleaned up.
[24/Jun/2013:08:16:07 -0400) - import userRoot: Indexing complete. Post-processing...
[24/Jun/2013:08:16:07 -0400) - import userRoot: Generating numSubordinates complete.
[24/Jun/2013:08:16:07 -0400) - import userRoot: Flushing caches...
[24/Jun/2013:08:16:07 -0400) - import userRoot: Closing files...
[24/Jun/2013:08:16:07 -0400) - entrycache_clear_int: there are still 5 entries in the entry cache.
[24/Jun/2013:08:16:07 -0400) - dncache_clear-int: there are still 918 dn's in the dn cache. :/
[24/Jun/2013:08:16:07 -0400) - import userRoot: Import complete. Processed 918 entries in 4 seconds. (229.50 entries/sac)
[24/Jun/2013:08:16:07 -0400] NSMMReplicationPlugin - multimastar_be_state_change: replica dc:xxxxxx,dc=com is coming on
line: enabling replication
[24/Jun/2013:08:16:07 -0400] NSMMReplicationPlugin - replica_configure_ruv: failed to create replica ruv tombstone entry (dc=xxxxxx,dc-com): LDAP error - 68
I would like to add that all replicas that could not be configured due to the reported errors were installed on Solaris 10 on Sparc processors, whereas the only replica that was initialized successfully was installed on Solaris 10 on i386 processors.
Thanks,
Jovan
Jovan Vukotić * Senior Software Engineer * Ambit Treasury Management * SunGard * Banking * Bulevar Milutina Milankovića 136b, Belgrade, Serbia * tel: +381.11.6555-66-1 * jovan.vukotic(a)sungard.com<mailto:jovan.vukotic@sungard.com>
[Description: Description: Description: Description: Description: coc-signature-03-2012]<http://www.capitalize-on-change.com/?email=70150000000Y1Et>
Join the online conversation with SunGard's customers, partners and Industry experts and find an event near you at: www.sungard.com/ten<http://www.capitalize-on-change.com/?email=70150000000Y1Et>.
From: Vukotic, Jovan
Sent: Saturday, June 22, 2013 11:59 PM
To: '389-users(a)lists.fedoraproject.org'
Subject: fresh replica reports "reloading ruv failed " just after successfull initialization.
Hi,
We have four 389 DS, version 1.2.11 that we are organizing in multi-master replication topology.
After I enabled all four multi-master replicas and initialized them - from the one, referent replica M1 and Incremental Replication started, it turned out that only two of them are included in replication, the referent M1 and M2 (replication is working in both direction)
I tried to fix M3 and M4 in the following way:
M3 example:
removed replication agreement M1-M3 (M2-M3 did not existed, M4 switched off)
After several database restores of pre-replication state and reconfiguration of that replica, I removed 389 DS instance M3 completely and reinstalled it again: remove-ds-admin.pl + setup-ds-admin.pl. I configured TLS/SSL (as before), restarted the DS and enabled replica from 389 Console.
Then I returned to M1, recreated the agreement and did initialization of M3. It was successful again, in terms that M3 imported all the data, but immediately after that, to me strange errors were reported:
What confuses me is that LDAP 68 means that an entry already exits... even if it is a new replica. Why a tombstone?
Or to make the long story short: Is the only remedy to reinstall all four replica again?
22/Jun/2013:16:30:50 - 0400] - All database tnreaas now stopped // this is from a backup done before replication configuration
[22/Jun/2013:16:43:25 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica xxxxxxxxxx is going off line; disablin
g replication
[22/Jun/2013:16:43:25 -0400] - entrycache_clear_int: there are still 20 entries in the entry cache,
[22/Jun/2013:16:43:25 -0400] - dncache_clear_int: there are still 20 dns in the dn cache. :/
[22/Jun/2013:16:43:25 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access th
e database
[22/Jun/2013:16:43:30 -0400] - import userRoot: Workers finished; cleaning up..
[22/Jun/2013:16:43:30 -0400] - import userRoot: Workers cleaned up.
[22/Jun/2013:16:43:30 -0400] - import userRoot: Indexing complete. Post-processing...
[22/Jun/2013:16:43:30 -0400] - import userRoot: Generating numSubordinates complete.
[22/Jun/2013:16:43:30 -0400] - import userRoot: Flushing caches.
[22/Jun/2013:16:43:30 -0400] - import userRoot: Closing files.
[22/Jun/2013:16:43:30 -0400] - entrycache_clear_int: there are still 20 entries in the entry cache.
[22/Jun/2013:16:43:30 -0400] - dncache_clear_int: there are still 917 dn's in the dn cache. :/
[22/Jun/2013:16:43:30 -0400] - import userRoot: Import complete. Processed 917 entries in 4 seconds, (229.25 entries/sec)
[22/Jun/2013:16:43:30 -0400] NSMMRep1 icationPlugin - multimaster_be_state_change: replica xxxxxxxxxxx is coming online; enabling
replication
[22/Jun/2013:16:43:30 -0400] NSMMReplicationPlugin - replica_configure_ruv: failed to create replica ruy tombstone entry (xxxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:43:30 -0400] NSMMReplicationPlugin - replica_enable_replication: reloading ruv failed
[22/Jun/2013:16:43:32 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:44:02 -0400] NSMMReplicationPlugin - replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:44:32 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:45:02 -0400] NSMMReplicationPluyin - _replica_confiyure_ruv: failed to create replica ruv tombstone entry (xxxxxxxx); LDAP error - 68
[22/Jun/2013:16:45:32 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:46:02 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
Any help will be appreciated.
Thank you.
Jovan Vukotić * Senior Software Engineer * Ambit Treasury Management * SunGard * Banking * Bulevar Milutina Milankovića 136b, Belgrade, Serbia * tel: +381.11.6555-66-1 * jovan.vukotic(a)sungard.com<mailto:jovan.vukotic@sungard.com>
[Description: Description: Description: Description: Description: coc-signature-03-2012]<http://www.capitalize-on-change.com/?email=70150000000Y1Et>
Join the online conversation with SunGard's customers, partners and Industry experts and find an event near you at: www.sungard.com/ten<http://www.capitalize-on-change.com/?email=70150000000Y1Et>.
10 years, 3 months
Authentication method not supported
by ilmir＠atacom.kz
Hello!
During the setup the Kolab on system with 389-ds I have found the
following message:
Your new DS instance 'xat' was successfully created.
Creating the configuration directory server . . .
Could not authenticate as user
'uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot' to
server 'ldap://xat.example.kz:389/o=NetscapeRoot'. Error: Authentication
method not supported
I thought that may be this is bug of kolab but new instance have the same
problem.
[root@xat noarch]# ldapsearch -x -D "uid=kolab-service,ou=Special
Users,dc=example,dc=kz" -w secret -b "dc=example,dc=kz" -s sub
"(objectclass=*)"
ldap_bind: Authentication method not supported (7)
additional info: auth method not supported
[root@xat noarch]# ldapsearch -x -D "cn=directory manager" -w secret -s
base
dn:
objectClass: top
namingContexts: dc=example,dc=kz
namingContexts: o=netscaperoot
defaultnamingcontext: dc=example,dc=kz
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.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: 2.16.840.1.113730.3.6.5
supportedExtension: 2.16.840.1.113730.3.6.6
supportedExtension: 2.16.840.1.113730.3.6.7
supportedExtension: 2.16.840.1.113730.3.6.8
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.42.2.27.9.5.8
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: GSSAPI
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: LOGIN
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.3.0.6 B2013.101.06
dataversion: 020130629192303020130629192303
netscapemdsuffix: cn=ldap://dc=xat,dc=example,dc=kz:389
I understand the this not the problem of credential and passwords. But it
the problem of authentication mechanism of LDAP
But where is core of this problem?
P.S: 389-ds is installed on Fedora 18 for PPC64
Thank you!
--
Ilmir Mulyukov
10 years, 4 months
389-console LDIF export question
by Michael Lang
Dear all,
I would like to clarify how the procedure to "export -> LDIF" through
the 389-console GUI is done (or how if reproduce should be done).
As far as I've understood the exports on the server itself is done
through creating a appropriate entry in cn=export,cn=task,cn=config
For "remote" machines using the GUI this isn't valid as the nsFilename
attribute requires a local write able location. What I've seen through
looking at the
LDAP protocol queries done during an export-to-ldif on console machine
task is a query to the schema listing all attributeTypes which are then
sent as attribute-retrieve-list in the ldap search. At least that's how
I was able to reproduce the same LDIF from GUI-Console export and
manually. Is this correct and should this be done in that way ? (I've
noticed also the "Warning: If you don't have permissions" statement when
using the LDIF export in the Console which more-or-less ack's my approach)
thanks for any hint.
regards
Mike
10 years, 5 months
Problems upgrading from PassSync 1.4 to PassSync 1.5
by Juan Carlos Camargo
Hi list,
I was expecting these new changes in PassSync (moreover those related to the 8th bit handling) , so congrats for the advances. I've found the following when I've tried the upgrade the product on one of my 2003 32bits windows controllers:
1.- I cannot simply update. The installed version was 1.4. A message tells me to uninstall the previous version and reinstall.
2.- If I uninstall the previous version, restart and install 1.5 from scratch, the installer stops when it tries to start the PassSync service , the rolls back the setup and does nothing. Error 1603 appears in the event viewer. I've troubleshooted this error according to Microsofts kb but none of the symptoms match my scenario.
I've tried the upgrade of my other two windows2003 x32 controllers , but I'm asked to upgrade windows installer first. All in all , could those problems relate to an old windows installer version? I havent updated it yet, just needed to make sure first. Could also be related to the way the 1.5 .msi was generated?
Regards!
--
Juan Carlos Camargo Carrillo.
@jcarloscamargo
957-211157 , 650932877
10 years, 5 months
SSL SAN Cert not trusted
by Justin Edmands
I am trying to create a SAN cert in order to cover both of my Master LDAPS
servers.
I was hoping to have the following:
hqdirsrv1\
> hqdirsrv
hqdirsrv2/
This will allow some of the older code to reference a single LDAP/S server
and not completely rely one instance.
- Creating a normal SSL cert works perfectly fine from my self signed CA.
Fully functional server
- Creating a SAN cert, exporting it, and importing it to the two Masters
works fine.
- In the Admin GUI, Manage Certificates shows the proper SAN certificate
and proper CA associated with this SAN cert.
- Starting (or restarting after saving the encryption stuff) the directory
server succeeds, but with the following error:
[root@hqdirsrv1 slapd-hqdirsrv1]# service dirsrv start
Starting dirsrv:
hqdirsrv1...[25/Jun/2013:11:55:45 -0400] - SSL alert:
CERT_VerifyCertificateNow: verify certificate failed for cert
Server-Cert-hqdirsrv-SAN of family cn=RSA,cn=encryption,cn=config (Netscape
Portable Runtime error -8172 - Peer's certificate issuer has been marked as
not trusted by the user.)
[ OK ]
Am I missing a cert or setting for a cert anywhere?
Because this is in dev right now, I trashed my old instance and started
fresh without any ldif imports, etc...same results.
10 years, 5 months
fresh replica reports "reloading ruv failed " just after successfull initialization.
by Jovan.VUKOTIC＠sungard.com
Hi,
We have four 389 DS, version 1.2.11 that we are organizing in multi-master replication topology.
After I enabled all four multi-master replicas and initialized them - from the one, referent replica M1 and Incremental Replication started, it turned out that only two of them are included in replication, the referent M1 and M2 (replication is working in both direction)
I tried to fix M3 and M4 in the following way:
M3 example:
removed replication agreement M1-M3 (M2-M3 did not existed, M4 switched off)
After several database restores of pre-replication state and reconfiguration of that replica, I removed 389 DS instance M3 completely and reinstalled it again: remove-ds-admin.pl + setup-ds-admin.pl. I configured TLS/SSL (as before), restarted the DS and enabled replica from 389 Console.
Then I returned to M1, recreated the agreement and did initialization of M3. It was successful again, in terms that M3 imported all the data, but immediately after that, to me strange errors were reported:
What confuses me is that LDAP 68 means that an entry already exits... even if it is a new replica. Why a tombstone?
Or to make the long story short: Is the only remedy to reinstall all four replica again?
22/Jun/2013:16:30:50 - 0400] - All database tnreaas now stopped // this is from a backup done before replication configuration
[22/Jun/2013:16:43:25 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica xxxxxxxxxx is going off line; disablin
g replication
[22/Jun/2013:16:43:25 -0400] - entrycache_clear_int: there are still 20 entries in the entry cache,
[22/Jun/2013:16:43:25 -0400] - dncache_clear_int: there are still 20 dns in the dn cache. :/
[22/Jun/2013:16:43:25 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access th
e database
[22/Jun/2013:16:43:30 -0400] - import userRoot: Workers finished; cleaning up..
[22/Jun/2013:16:43:30 -0400] - import userRoot: Workers cleaned up.
[22/Jun/2013:16:43:30 -0400] - import userRoot: Indexing complete. Post-processing...
[22/Jun/2013:16:43:30 -0400] - import userRoot: Generating numSubordinates complete.
[22/Jun/2013:16:43:30 -0400] - import userRoot: Flushing caches.
[22/Jun/2013:16:43:30 -0400] - import userRoot: Closing files.
[22/Jun/2013:16:43:30 -0400] - entrycache_clear_int: there are still 20 entries in the entry cache.
[22/Jun/2013:16:43:30 -0400] - dncache_clear_int: there are still 917 dn's in the dn cache. :/
[22/Jun/2013:16:43:30 -0400] - import userRoot: Import complete. Processed 917 entries in 4 seconds, (229.25 entries/sec)
[22/Jun/2013:16:43:30 -0400] NSMMRep1 icationPlugin - multimaster_be_state_change: replica xxxxxxxxxxx is coming online; enabling
replication
[22/Jun/2013:16:43:30 -0400] NSMMReplicationPlugin - replica_configure_ruv: failed to create replica ruy tombstone entry (xxxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:43:30 -0400] NSMMReplicationPlugin - replica_enable_replication: reloading ruv failed
[22/Jun/2013:16:43:32 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:44:02 -0400] NSMMReplicationPlugin - replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:44:32 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:45:02 -0400] NSMMReplicationPluyin - _replica_confiyure_ruv: failed to create replica ruv tombstone entry (xxxxxxxx); LDAP error - 68
[22/Jun/2013:16:45:32 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
[22/Jun/2013:16:46:02 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (xxxxxxxxx); LDAP error - 68
Any help will be appreciated.
Thank you.
Jovan Vukotić * Senior Software Engineer * Ambit Treasury Management * SunGard * Banking * Bulevar Milutina Milankovića 136b, Belgrade, Serbia * tel: +381.11.6555-66-1 * jovan.vukotic(a)sungard.com<mailto:jovan.vukotic@sungard.com>
[Description: Description: Description: Description: Description: coc-signature-03-2012]<http://www.capitalize-on-change.com/?email=70150000000Y1Et>
Join the online conversation with SunGard's customers, partners and Industry experts and find an event near you at: www.sungard.com/ten<http://www.capitalize-on-change.com/?email=70150000000Y1Et>.
10 years, 5 months
Dirsrv-admin - dsgw issue with authentication
by Zane Williamson
Hi 389-users list!
I appear to have an issue holding onto authentication when attempting to
save changes to an ldap entry.
I am able to authenticate properly, but when I attempt to "Save Changes"
It takes me to:
https://mydomain.net/dsgwcmd/domodify
Where it says Problem in the header and the page contains.
Warning: no authentication (continuing)...
It is perplexing me because I was able to verify with the domain admin on
the previous pages, but the "domodify" cgi appears to not have the prior
authentication information provided.
Any else see issues like this?
Here is what I am running:
389-admin-1.1.9-1.el5
389-adminutil-1.1.8-4.el5
389-ds-base-1.2.5-1.el5
389-dsgw-1.1.4-1.el5
Thanks!
Zane
10 years, 5 months
