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, 7 months
MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser
Hi,
I'm new to 389-ds and last week downloaded and installed the software.
I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query
the server using TLS/SSL, and all appears working.
I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client
can see the unix users and groups using the "getent password" or "getent group" commands.
Now, here's where I'm getting tripped up..........
I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations.
I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-grou...)
which is close enough to CentOS that the initial commands worked.
I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system.
I created a test group (that I didn't enable a posix GID) and tried to add a single user via:
Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add.
When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error:
"Cannot save to directory server.
netscape.ldap.LDAPException: error resiult(65): Object class violation"
And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors:
"Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed
[17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)"
So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before
I even try to filter login access via groups on my client system.
I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I
should set the "value" to be.
I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute
on individual users, only groups.
This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions.
Any suggestions would be appreciated.
3 years, 8 months
How to invalidate local cache after user changed their password
by xinhuan zheng
Hello,
I have been struggling with this problem for a while. When a user changed their password, our 389 directory servers received new password and saved into directory server. However, when user tries to login to a server whose authentication is using 389 directory server, their new password won't work for the first few minutes. There is a local cache process, sssd, running on the server the user tries to login. Apparently sssd is still using old password information, and does not know password has changed on directory servers. I have set sssd to keep cache information for 5 minutes only, and do pre-fetch prior to cache information expiring. But I don't know how to tell sssd to ignore cache completely when information has changed on 389 directory server side.
Is there a way to completely disable sssd local cache, and only use it when 389 directory servers are not available?
Thank you,
- Xinhuan
5 years, 1 month
Referential Integrity and moving subtree to another parent fails
by Olivier JUDITH
Hi,
I have activated Referential Integrity plugin on my instance in order to move several OU to a new parent subtree. Also to update automatically uniqueMember attribute defined in group member .
It works fine with few user entries under some OU but fails when the OU contains more than 400 entries or somtime more than 800.
The error from the 389-console is :
ou=UNITA, OU=Accounts,dc=mydomain,dc=com: netscape.ldap.LDAPException: error result (1); Operations error.
In error file
[20/Feb/2019:17:37:59.123749991 +0100] - ERR - ldbm_back_modrdn - SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set SLAPI_RESULT_CODE
After this error the OU : UNITA, OU=Accounts,dc=mydomain,dc=com is not visible from 389-console . I have to restart the instance in order to recover the OU.
Did i miss something in my configuration or do i have to set a specific parameter to support big entries ?
My installation : 389DS 1.3.6 .
5 years, 1 month
Samba & 389 Directory Server Integration
by Janet Houser
Hi Folks,
I'm running DS-389 (version: 1.3.7.5 ; Build: 2018.178.1311) on a Cent
OS 7 vs. 7.6.1810) system. I've been working
through the Samba & 389 Directory Server Integration
<https://directory.fedoraproject.org/docs/389ds/howto/howto-samba.html#stq...>
doc and I've hit a snag. I've obtained my SID using the "net getlocalsid"
command, but when I create my .ldif file (see below):
[root]# cat sambaDomainName.ldif
dn: sambaDomainName=WORKGROUP,dc=test,dc=example,dc=com (changed for
security)
objectclass: sambaDomain
objectclass: sambaUnixIdPool
objectclass: top
sambaDomainName: WORKGROUP
sambaSID: S-1-5-21-xxxxxxxxx-xxxxxxxx-xxxxxxx (removed for security)
uidNumber: 550
gidNumber: 550
And attempt to import it into my DS server using:
/usr/lib64/dirsrv/slapd-<name>/ldif2ldap "cn=Directory manager"
password ./sambaDomainName.ldif
/usr/lib64/dirsrv/slapd-<name>/ldif2ldap "cn=Directory
manager,dc=test,dc=example,dc=com" password ./sambaDomainName.ldif
I get an error:
Options:
-Z serverID - Server instance identifier
-D rootdn - Directory Manager DN
-w passwd - Directory Manager password
-f file - File containing LDAP entries to add to the server
-P protocol - STARTTLS, LDAPS, LDAPI, LDAP
-h - Display usage
I tried modifying the command in various ways:
/usr/lib64/dirsrv/slapd-<name>/ldif2ldap -D "cn=Directory Manager" -w
<my DS password> -f /sambaDomainName.ldif
and I've even used the /usr/sbin/ldif2ldap executable and have only
gotten errors about the usage. From the messages it looks like I
don't need the -Z server ID in the command since I have only one
instance running on the server.
I'm sure I'm missing the obvious but I was hoping an experienced eye
might have an easier time finding it.
Any suggestions would be appreciated.
Thanks,
5 years, 1 month
Setting an attribute value automatically according to some rule
by Rosario Esposito
Hello,
let's say whenever I create a new entry:
uid=myuser,ou=people,dc=example,dc=com
I would like this entry to have the attribute:
mail: myuser(a)example.com
(i.e. the value of 'mail' should be automatically set to the value of
'uid' + '@example.com')
Is there a way for 389ds to do this task automatically ?
Thanks,
--
Rosario Esposito
System Administrator
INFN - Napoli
Phone: +39 081 676170
Email: Rosario.Esposito(a)na.infn.it
5 years, 1 month
Re: Replicate 389DS with another LDAP server
by Howard Chu
> Date: Wed, 20 Feb 2019 15:35:46 +0100
> From: Ludwig Krispenz <lkrispen(a)redhat.com>
> On 02/20/2019 03:24 PM, Howard Chu wrote:
>> > Mark Reynolds wrote:
>>> >> On 2/20/19 5:59 AM, Howard Chu wrote:
>>>>> >>>> Date: Tue, 19 Feb 2019 13:50:11 +0100
>>>>> >>>> From: wodel youchi <wodel.youchi(a)gmail.com>
>>>>> >>>>
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> is it possible to create a replication matser/master or master/slave
>>>>> >>>> between 389DS and another LDAP server openldap for example?
>>>>> >>>>
>>>>> >>>> Regards.
>>>> >>> Maybe. OpenLDAP has recently added support for replication using a retro changelog.
>>>> >>> It has only been tested against Sun/Oracle DSEE so far
>>> >> 389's retro changelog should be the same as DSEE, so this would be an option. Howard, does this new replication feature in OpenLDAP work in both directions?
>> > Not at the moment. It only allows OpenLDAP to replicate from DSEE. It probably wouldn't be
>> > difficult to write an overlay to generate a compatible changelog, for going the other
>> > direction.
> 390ds also impelments SyncRepl as a plugin, so this could also be an
> option to try, but it would still provide only the direction 389ds
> -->openldap.
> For the other direction 389ds would have to offer some "pull
> replication" feature, which doesn't exist.
Not necessarily. OpenLDAP can also push changes; this configuration is sometimes
needed for syncrepl behind various firewall setups.
> A further problem would be in synchronizing updates from several
> sources, 389ds uses CSNs and RUVs, openldap also has CSN, which are a
> similar concept, but not directly compatible.
> So, even if there are approaches to do it, I think we are not there.
Indeed, I don't see a straightforward way to support master/master at the moment.
But for typical provider/consumer replication it could be done, with a couple
remappings of operational attributes in the middle.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 2 months
389-DS on CentOS 6.10
by Sandra Poole
I'm attempting to do something I've never done before.
When I was employed the company I worked for used Windows Active
Directory and they had a staff of 8 to maintain all of that for the
entire corporation. As a Linux System Admin I had access to a place in
the Directory structure for Linux/Solaris/AIX servers and we kept our
'stuff' correct using a third party software.
Now that I am retired I do not have those resources. And I only have 3
Windows machines that are old and only used for the internet / email access.
My Linux environment is growing (both planned and unplanned). When I
retired I was allowed to purchase several older tower servers for
practically free, all I had to do was just clean off the hard drives
with Data Center staff watching + $50. So I went from 2 physical
machines to 8 machines with all having multiple hard drives and none
less that 24 GB RAM.
I've finally gotten them running and configured with CentOS 6.10 x86_64
and using software RAID-1 or software RAID-1 and RAID-10.
What I want to do with 389-DS is to guarantee the following:
1. Every machine with the same users has the same passwords
2. Maintenance jobs are run the same everywhere.
3. All Virtual Machines (regardless if they are using KVM or
VirtualBox) 'look' the same (there are 36 virtual machines - so far).
4. Any other thing that comes up.
5. 'Talk' to a virtual machine that is not Linux but has a LDAP client.
What I can't seem to locate is a tutorial or some other document that
explains to a layman how to migrate users, passwords, and configuration
information into my recently installed 389-DS.
Can someone give me some information?
TIA
Sandy
5 years, 2 months
Re: Replicate 389DS with another LDAP server
by Howard Chu
> Date: Tue, 19 Feb 2019 13:50:11 +0100
> From: wodel youchi <wodel.youchi(a)gmail.com>
>
> Hi,
>
> is it possible to create a replication matser/master or master/slave
> between 389DS and another LDAP server openldap for example?
>
> Regards.
Maybe. OpenLDAP has recently added support for replication using a retro changelog.
It has only been tested against Sun/Oracle DSEE so far but it may also work with
389DS/RHDS, and if it doesn't work at the moment it probably wouldn't take much to
make it work. I haven't examined the 389DS schema to see how closely it matches DSEE yet.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 2 months
