gmane.linux.redhat.fedora.directory.user

Using Wildcard SSL Certificate

Jeff Field — 2012-05-26T04:41:43

Hello,
I'm attempting to use a Wildcard SSL certificate for my domain with 389ds.
The certificate and the CA (godaddy) intermediate cert import fine into
both the admin server and the directory server, but attempts to use an
LDAPS:// URI with ldapmodify result in this error:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

curl gets this:

curl -vvv -3 https://myserver.ldap.mydomain.com:636
* About to connect() to myserver.ldap.mydomain.com port 636 (#0)
*   Trying x.x.x.x... connected
* Connected to myserver.ldap.mydomain.com (x.x.x.x) port 636 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL: certificate subject name '*.mydomain.com' does not match target host
name 'myserver.ldap.mydomain.com'
* NSS error -12276
* Closing connection #0
curl: (51) SSL: certificate subject name '*.mydomain.com' does not match
target host name 'myserver.ldap.mydomain.com'

Am I not able to use a wildcard SSL cert in this instance? If that is the
case, what would my best course of action be?

Thanks,
-Jeff
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

About 389 cache and backend behavior

Roberto Polli — 2012-05-24T15:49:44

Hi all,

where can I find a brief description of the 389 communication between:
 - client
 - 389 cache
 - 389 backend
 - COS and VLV 

Is there a way to dwell into it without reading the code?

Thx+ Peace,
R.

Upgrade to fedora 16 with real CA fails

Chris Cawley — 2012-05-23T18:59:05

Hello,



    I went through some of the docs/emails; however, it still seems like

    The NSS is not working correctly.

    On a separate, but related issue, it seems like you cannot use

    the GUI to generate a key with 2048 bits.  To get a real CA, some

    vendors ask for this.

        -          Thanks
        -          Chris

Chris Cawley
System Administrator
Washington Research Library Consortium
301-390-2049
cawley< at >wrlc.org


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Disable unhashed#user#password altogether

Lucas Sweany — 2012-05-22T21:32:14

Is there a way to prevent the unhashed#user#password attribute from being
stored or used at all? I don't need it to be replicated anywhere--I presume
that the hashed password will be enough to authenticate users.

Thanks,

-Lucas
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

subtree stacking/subtree virtual views

Petr Spacek — 2012-05-22T17:18:53

Hello,

I'm looking for some way how to "stack" LDAP sub-trees one on top of another.

What I mean: Let's have two subtrees:
dc=lower  and  dc=upper

dc=lower contains objects:
cn=obj1
cn=obj2,attr A = 2
cn=obj3


dc=upper contains objects:
cn=obj2,attr A = 4
cn=obj4


Now I push dc=upper on top of dc=lower (let say it creates dc=stack)
Queries with base dc=stack will return:
cn=obj1 --> same object as in dc=lower
cn=obj2 --> same object as in dc=upper, attr A = 2
cn=obj3 --> same object as in dc=lower
cn=obj4 --> same object as in dc=upper

I saw overlays "relay" and "rwm" in OpenLDAP. Is there any support in 389 for 
this use case?


I need to override several records from "lower" subtree with object from 
"upper" subtree. Problem is, that subtree "lower" can contain 10 000 objects 
and I need to override only 5 of them. I'm searching for effective way how to 
accomplish this without copying whole subtree "lower" to "upper".


Thanks for your time.

Petr^2 Spacek
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

compressed log files

Michael R. Gettes — 2012-05-21T15:18:10

Hi,  I figured I would ask the question here before proceeding with a RFE.

I searched TRAC and couldn't locate any relevant tickets.

I'd like to have 389 compress rotated log files to save significant amounts of disk space.  Additionally, logconv.pl and other relevant tools would need to be modified to dynamically uncompress logfiles being processed (yes, I know I could gunzip -c and stuff like that but it would be easy to modify the tool to "do the right thing").  Is this a reasonable RFE or is it deemed "out of scope"?

thanks

/mrg
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

cannot build admin-console on Mandriva

Liutauras Adomaitis — 2012-05-21T05:47:09

Hi all,

this is my acquaintance with 389 directory server. I need to build
admin console so I can connect to an installed server.
I'm following instructions in
http://directory.fedoraproject.org/wiki/BuildingConsole
Everything went fine up until "Building Directory Server Console
(389-ds-console)".
Then I launch ant in the 389-ds-console directory I get:

Buildfile: build.xml

prepare_build:

import_console:
    [input] An imports file must be specified.  Enter the imports file
that you want to use: [imports]
imports.FC3
    [mkdir] Created dir: /usr/local/src/imports/console
      [get] Getting:
http://port389.org/built/components/console/1.0/20051027/RHEL4_x86_gcc3_OPT.OBJ/console10.tar.gz
      [get] To: /usr/local/src/imports/console/console10.tar.gz
      [get] Error opening connection java.io.FileNotFoundException:
http://port389.org/built/components/console/1.0/20051027/RHEL4_x86_gcc3_OPT.OBJ/console10.tar.gz
      [get] Error opening connection java.io.FileNotFoundException:
http://port389.org/built/components/console/1.0/20051027/RHEL4_x86_gcc3_OPT.OBJ/console10.tar.gz
      [get] Error opening connection java.io.FileNotFoundException:
http://port389.org/built/components/console/1.0/20051027/RHEL4_x86_gcc3_OPT.OBJ/console10.tar.gz
      [get] Can't get
http://port389.org/built/components/console/1.0/20051027/RHEL4_x86_gcc3_OPT.OBJ/console10.tar.gz
to /usr/local/src/imports/console/console10.tar.gz

BUILD FAILED
/usr/local/src/389-ds-console-1.2.6/build.xml:71: Can't get
http://port389.org/built/components/console/1.0/20051027/RHEL4_x86_gcc3_OPT.OBJ/console10.tar.gz
to /usr/local/src/imports/console/console10.tar.gz

Then prompted for import file I specified import.FC3 file. Which, as
far as I can see, provides URL to download installer a file, but the
URL is not valid as you can see from install log.

I have downloaded these versions so far:
389-console-1.1.7.tar.bz2
389-ds-console-1.2.6.tar.bz2
idm-console-framework-1.1.7.tar.bz2

Any ideas?
thanks
Liutauras
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

unhashed#user#password field

Alberto Viana — 2012-05-18T18:13:37

I have a 389 DS server replication agreement whith an AD Server and when I
change the password in the windows side it replicates into 389 but via 389
console I can see this field "unhashed#user#password" in clear text.

How can I encrypt this field? Is it possible?


I tried the following configuration:

Source:
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases-Creating_and_Maintaining_Databases.html#Creating_and_Maintaining_Databases-Database_Encryption

dn: cn=unhashed#user#password,cn=encrypted attributes,cn=userRoot,cn=ldbm
data
base,cn=plugins,cn=config
objectClass: top
objectClass: nsAttributeEncryption
cn: unhashed#user#password
nsEncryptionAlgorithm: AES

If I restart my server the field is gone.

The fact is that I need to avoid my admin to see the user´s password.
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Sync with active directory doubts

Alberto Viana — 2012-05-17T21:26:04

Hello,

I have 2 389 DS servers a 6 AD servers and i read this on red hat
documetation about windows replication:

"There can only be a single sync agreement between the Directory Server
environment and the Active Directory environment. Multiple sync agreements
to the same Active Directory domain can create entry conflicts."

Now I´m trying the following scenario:


server2 389(consumer) <- replication -> server1 389 <- replication ->
Server1 AD

                   Server2 AD

                   Server3 AD

So in my master 389 server (server1) I have 3 agreements with 3 different
AD servers. It´s not clear if "Active Directory environment" means just one
AD server.

Just to make clear that the 6 AD servers are in the same Active Directory
domain and all replicate information with each other. I have this number of
AD servers because they are located in different places(physically).


Can this scenario create entry conflitc? Am I suppose to sync with just one
AD server?



Thanks,

Alberto Viana
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Strange Disk IO issue

Brad Schuetz — 2012-05-14T23:54:11

I have recently upgraded our 389 servers from pretty old versions that
were a mix and match of 389 release and CentOS released versions (all on
centos 5) to the latest (on centos6) (specific RPMs listed below).

I did this though a full ldif dump of the original server and imported
into a freshly installed new master server.  Then I setup the
replication agreements with the 7 slave servers and everything was
running fine. 

After about a week I starting having a problem with the hubs servers
where all of them after (possibly exactly) 24 hours would start going
crazy on the disk IO (95-100% according to sysstat) of that server
making queries to ldap slow.  The master server does not exhibit this
problem, it will run completely fine.

A simple restart of the dirsrv process corrects the issue and then it
will run for another 24 hours before repeating the issue.

The hardware running each node is somewhat different with varying disk
speeds underlying, but all exhibit the same behavior.

This happens the same on the 2 nodes that get relatively little traffic
and the 5 nodes that get a lot of traffic.

I was originally on the 389-ds-base release that shipped with CentOS6
and have changed to the version from the
<http://repos.fedorapeople.org/repos/rmeggins/389-ds-base/epel-389-ds-base.repo>
repo, both do the same thing.

Any thoughts/suggestions on how to fix or further diagnose this?  I've
had no luck with strace or error logs to find any issues.  At this point
I've unfortunately had to resort to a cron job to restart all of my LDAP
hubs.

Installed RPMs:
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-console-1.1.7-1.el6.noarch
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
389-admin-1.1.29-1.el6.x86_64
389-ds-base-1.2.10.7-1.el6.x86_64
389-adminutil-1.1.15-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-base-libs-1.2.10.7-1.el6.x86_64

--
Brad
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

disabled user attribute

Alberto Viana — 2012-05-11T14:51:21

I have an 389 DS server 1.2.10 and I disabled/inactivated  a user just for
test (via 389 console) but I could not find what attribute was modified
with this change. I need to know how to identify a disabled/inactivated
user.
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Issue with schema replication

Moisés Barba Pérez — 2012-05-10T12:37:22

Hi,

I'm upgrading one 389DS machine from 1.2.5 to 1.2.10.7 and I have found a
problem when replicate the schema from another 1.2.5 DS machine.

I had created an attribute like this:

attributeTypes: (
  <OIDXXXXXXX>
  NAME 'xxxxx'
  DESC 'yyyyy'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
  SINGLE-VALUE
  )

and at replication time get this error:

[10/May/2012:14:35:31 +0200] attr_syntax_create - Error: the EQUALITY
matching rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [xxxxx]

   Is there a default equality matching rule for this manual attributes???
Have I to modify the attribute with a equality matching rule for it in the
original 1.2.5 DS to be able to replicate??? Is it a problem between
versions??? If someone could help me i will appreciate it.

Regards,
Moses.
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Cannot Initialize Hub

Paul M. Whitney — 2012-05-09T20:18:39

Hi, I am having a problem with LDAP multi-master environment.  I am trying to initialize a new hub (first one crashed so this is a new build with same hostname).  

When I exported the LDIF file from master and imported to hub there were no errors.  I then created a replication agreement from master to hub. When I try to send updates, I get error on hub error log:  csngen limit exceeded value 129888, limit 86400.

Is there a way to reset the skew or "force" the replication?



Paul M. Whitney
paul.whitney< at >me.com

--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Disable Inactive Users After 90 days

Ali Jawad — 2012-05-09T13:45:20

Hi
I have a requirement to disable inactive users after 90 days. I did read
http://directory.fedoraproject.org/wiki/Account_Policy_Design  but I am not
sure whether this is a design proposal or the actual implementation.

My DS version is :

rpm -qa | grep 389
389-admin-console-1.1.8-1.el5
389-ds-base-1.2.9.9-1.el5
389-dsgw-1.1.7-2.el5
389-console-1.1.7-3.el5
389-adminutil-1.1.14-1.el5
389-admin-1.1.23-1.el5
389-admin-console-doc-1.1.8-1.el5
389-ds-1.2.1-1.el5
389-ds-base-libs-1.2.9.9-1.el5
389-ds-console-1.2.6-1.el5
389-ds-console-doc-1.2.6-1.el5

I got

[root< at >386-100-16 dirsrv]# ldapsearch -x -D "cn=Directory manager" -w
Password -b "cn=config" -s base lastLoginTime
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope baseObject
# filter: (objectclass=*)
# requesting: lastLoginTime
#

# config
dn: cn=config

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

and

[root< at >386-100-16 dirsrv]# grep -i lastlogintime
/etc/dirsrv/slapd-386-100-16/schema/*
/etc/dirsrv/slapd-386-100-16/schema/60acctpolicy.ldif:## lastLoginTime
holds login state in user entries (GeneralizedTime syntax)
/etc/dirsrv/slapd-386-100-16/schema/60acctpolicy.ldif:attributeTypes: (
2.16.840.1.113719.1.1.4.1.35 NAME 'lastLoginTime'

I am not sure how to implement this though, please advice.

Regards
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

idle_timelimit 60

Ali Jawad — 2012-05-09T08:04:31

Hi
I know this is not a strictly 389 DS related question. I did
set idle_timelimit 60 in my /etc/ldap.conf client file but connections
stay running and do not time out. Is there any setting I need to add on the
server side ?



My Full Ldap file at /etc/ldap.conf

bind_policy soft
URI ldap://xx.xx.xx.xx
BASE dc=xxxxxxx,dc=local
TLS_CACERTDIR /etc/openldap/cacerts
pam_password clear
pam_lookup_policy yes

idle_timelimit 60

Regards
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

No password change forced at first logon

Ali Jawad — 2012-05-08T11:26:25

Hi
I did check the box that says User Must Change Password After Reset in Data
under configuration I also did set the same policy for specific users.
However, I am not being asked to change password on first logons through
ssh or direct console on server, the same is true when I do change the
password of a user "I guess this is what password reset means".
I am not using Fine Grain Password settings.
Any ideas ?
Thanks
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Issues with 389 <-> AD sync and user creation

Orion Poplawski — 2012-05-07T23:33:29

We're trying to modify our already heavily modified version of fdstools to add 
ntUser attributes to users.  When we use it to create a new user (or add 
ntUser attributes to and existing user) we end up with two new users in AD and 
the cn: attribute of the user in 389 is modified to have CNF:<guid> added 
which indicates a conflict in the database.

If we check the Enable NT User Attributes and create New NT Account in 
389-console everything seems to work.  We're not able to see what we're doing 
differently.  Except that perhaps 389-console is setting ntUniqueId, but I 
didn't think it was supposed to do that, that the AD sync was supposed to 
handle it.

In fdstools we're setting ntUserDomainId, ntUserCreateNewAccount, and 
ntUserDeleteAccount.  Which seems to be all we need to do according to 
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Using_Windows_Sync-Synchronizing_Users.html#ftn.id4791561

389-ds-1.2.1-1.el5
389-ds-base-1.2.9.9-1.el5


Ideas?

TIA,

  Orion

How to change certificate options using 389-console ?

Addison Laurent — 2012-05-07T18:12:38

I'm trying to add a new server, and will need to use SSL, of course.
But all the instructions tell how to generate a self-signed CA, but
we've got real signed certs on the other servers, and so I'm trying to
generate a CSR for the new one.


Generating one from the 389-console is only giving me a 1024-bit key,
and 2048 is required.


I see that running the cert request from the command line is not the
preferred option, but how else can I change the parameters for the cert
request?


Thanks,
Addison


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Problems with nsaccountlock attribute

David Baird — 2012-05-07T05:11:06

Hi All,

Our instance of 389 (version 1.2.8.1 running on Centos 5.7) has recently begun 
exhibiting problems with account locking.

Locking (or inactivating if you prefer) an account, either by using the 389 
console, or the ns-inactivate.pl script works initially and the user object 
displays the correct attributes...

nsrole "cn=nsdisabledrole,dc=..." "cn=nsmanageddisabledrole,dc=..."
nsroledn "cn=nsManagedDisabledRole,dc=..."
nsaccountlock "true"

and an ldapsearch confirms the existence of the nsaccountlock attribute.

However, after some period of time has elapsed (haven't quite narrowed down 
exactly when it occurs) the nsaccountlock attribute is no longer present, 
meaning the account is no longer locked.

About two weeks ago, I removed all entries from nsManagedDisabledRole and 
restarted dirsrv, then inactivated approximately 16 accounts.  As of Thursday 
last week they were all still as expected with the nsaccountlock attribute 
present.  As of this morning (Monday) none of the accounts have the 
nsaccountlock attribute present.  The modifytimestamp for the user object 
remains unchanged, which would indicate an issue with the management of the 
virtual nsaccountlock attribute.

Does anyone have any idea what might be causing this? Replication is not an 
issue as we only have a single server. There is an AD sync agreement active, but 
it's my understanding that 389 cannot sync account locking with Active Directory.

Is the management of the virtual attribute nsaccountlock logged at all?  Is 
there a specific log level (either in access log or error log) that will give a 
clue as to what is happening?

Thanks in advance,
David.






--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Master index (?!) feature request?

Diego Woitasen — 2012-05-04T12:47:18

I didn't know how to title this mail. I think this should be a feature
request in Track when I want to discuss this here first.

I have 389DS with 150 DBs with an structure similar to this:

dc=company,dc=com
ou=Headquarters,dc=company,dc=com
ou=Branch1,dc=company,dc=com
ou=Branch2,dc=company,dc=com
.
.
.
ou=Branch150,dc=company,dc=com

Each one of this subtrees are in separate DBs because I have subtree
replication between the 150 branches of the companies.

80% of the objects are in the ou=HeadQuarters. I've noticed that the
performance is definetely better when I use base ou=Headquarters in my
applications.

I have indexes on each DB but I think that the problem is that 389DS
doesn't have a master index or something to improve the searchs in
scenarios like mine.

May be the solution is to implemen another replication code that
doesn't required separate DBs for subtree replication.

Shall I file a ticket? Or there is a solution now?

Regards,
 Diego

Solaris client, behavior differences?

Rafael Hinojosa — 2012-05-03T19:06:29

Hi,

My colleague and I are working on migrating from Sun One Directory Server
to 389 Directory Server.  We have successfully configured 389 Directory
Server on Centos 5.7.  We've been able to successfully setup Multi-Master
Replication and have joined (or at least it appears to) a Solaris 10
Client.

Here is a quick breakdown of what we're observing...

Solaris 10 host, as a 389 Client...

... can perform ldapsearch (using both directory manager & proxyagent
bindDNs).   It will return all entries (when using directory manager as the
bindDN) or a limited amount (2000, when search using proxyagent bindDN), as
specified by the configuration.
... using ldaplist requires an escaped wild card to list most of the DB,
again I'm assuming it is inheriting the proxyagent limits.
... executing "getent passwd" or "getent group" returns ONLY the local
users & groups.


Solaris 10 host, as a Sun One Client...

... using ldapsearch exhibits the same behavior.
... using ldaplist requires no wild card, we can simply execute "ldaplist
passwd" and get, surprisingly, all entries in the DB.
... can execute "getent passwd" or "getent group" and see all LDAP users
and groups.


Is this normal or have we screwed up some config somewhere?


We have yet to move on to tackling the PAM stack since we're trying to see
if this config is viable.

At the moment, as a local user on this 389 Client, we cannot su to another
LDAP user.  It just says sorry, /var/adm/messages just reads "su :
[auth.crit] 'su <USER>' failed for <LOCAL USER> on..."

We can su to another LDAP user as root w/o the need to specify a passwd,
which I'm assuming is the only reason that works.

My colleague is going to work on finding a viable PAM config.   Any clues,
leads, or references you can provide us for either anomalies would be
greatly appreciated.

Thank you for your time,

--Raf