Objectclass not enabled in PHPldapadmin
by Gokulnath Arjunan
Hi,
I have installed LDAP 2.4 version and using phpldapadmin to manage it. I am
not seeing all the options enabled in create object page. Like I can see
"Generic: Organisational Role" and "Generic: Organisational Unit" but other
options like "Generic: Address Book Entry, Generic: Posix Group, Generic:
User Account" are in disabled mode. I want them to be available to create
group and users. Please guide
me how to resolve this issue.
I noticed below errors/warning during login to phpldapadmin and not sure
about it.
Samba: Group Mapping: posixGroup removed from template as it is not defined
in the schema
Alias: inetOrgPerson removed from template as it is not defined in the
schema
Thanks
Gokulnath
7 years, 10 months
query across ou
by Chuck Theobald
Is there a way to perform a single query an LDAP database such that I
can retrieve the group name (cn) from a user's full name (cn). My
structure holds user accounts in ou=People and groups in ou=Group. I
know I can ask for gidNumber from the People tree, then reference the
group in the Group tree, but with an SQL background, I would like a
single query.
Thanks,
--
Chuck Theobald
System Administrator
The Robert and Beverly Lewis Center for Neuroimaging
University of Oregon
P: 541-346-0343
F: 541-346-0345
7 years, 10 months
Re: Antw: Re: All entries belong to the top object class?
by dE
On 04/21/15 11:43, Ulrich Windl wrote:
>>>> dE <de.techno(a)gmail.com> schrieb am 20.04.2015 um 07:36 in Nachricht
> <55349047.7020907(a)gmail.com>:
>> On 04/20/15 00:59, Ryan Tandy wrote:
>>> On Sun, Apr 19, 2015 at 11:42:16AM +0530, dE wrote:
>>>> As per https://tools.ietf.org/html/rfc4512#section-3.3
>>>>
>>>> When creating an entry or adding an 'objectClass' value to an entry,
>>>> all superclasses of the named classes SHALL be implicitly added as
>>>> well if not already present.
>>>>
>>>> That means the top object class will always be there.
>>> Basically correct. Note "implicitly" means it's treated as present,
>>> even if the entry doesn't actually contain "objectClass: top".
>>>
>>>> Or is it that only the most subordinate object class in the
>>>> multivalued attribute is considered by the client and server?
>>> The following facts may answer your question:
>>>
>>> - every entry satisfies the filter "(objectClass=top)".
>>>
>>> - an entry with "objectClass: inetOrgPerson" satisfies the filter
>>> "(objectClass=person)".
>>>
>> I'm concerned about the attributes. Does adding of the top object class
>> (or person) add all attributes to the entry?
> I'd say: It adds no attributes at all to the entry automagically, but the MUST attributes have to be provided while the MAY attributes may be provided. If an entry is created, it will contain all the valid attributes you provide (no entry is created if you supply invalid attributes).
>
> Regards,
> Ulrich
Yes, so subclasses do not define MAY; it's defined by the MAY of the top
object class.
7 years, 10 months
Re: Antw: Re: Slapd running very slow
by Geoff Swan
On 2015-04-23 4:07 PM, Ulrich Windl wrote:
>>>> Geoff Swan <gswan3(a)bigpond.net.au> schrieb am 22.04.2015 um 23:18 in Nachricht
> <5538100A.3060301(a)bigpond.net.au>:
>
> [...]
>> Free stats look fine to me. No swap is being used, or has been used yet
>> on this system.
>>
>> total used free shared buffers cached
>> Mem: 132005400 21928192 110077208 10612 363064 19230072
>> -/+ buffers/cache: 2335056 129670344
>> Swap: 8388604 0 8388604
>>
>> The effect I am seeing is that despite a reasonably fast disc system,
>> the kernel writing of dirty pages is painfully slow.
> So disk I/O stats is also available via sar. May we see them? Finally there's blktrace where you can follow the timing and positions of each individual block being written, but that's not quite easy to run and analyze (unless I missed the easy way).
>
> I suspect scattered writes that bring your I/O rate down.
>
> Regards,
> Ulrich
>
sysstat (and sar) is not installed on this system, so I can't give you
that output.
7 years, 10 months
OpenLDAP keeps on dying sporadically
by Leander Schäfer
Hi fellows
my OpenLDAP keeps on dying sporadically. Unfortunately it doesn't leave
ANY trace of why it crashes. It stays alive for a while .... takes a
couple of queries as expected ... and then suddenly it dies after
another request. This could mean working perfectly for a day or working
only for a couple of minutes before it crashes. The requests are all
known to work (Dovecot auth and system PAM auth). At first I thought it
could be related to newsyslog(8) ... I did some testing - unfortunately
this doesn't change anything at all. It keeps on dying sporadically even
if newsyslog is completely deactivated for the slapd(8) log file.
I experenced this behauviour since I first used OpenLDAP approximately 5
years ago. My OpenLDAP configurations have been changed many times and
quite a lot over those 5 years. Unfortunately I was never able to figure
out what the sudden crashes caused - so I wrote a supervisor script ,
which periodically checks if the slapd(8) is still running. If slapd(8)
is not running, then my supervisor script starts it automatically again.
Of course with every major change in the configuration of OpenLDAP, I
also tried to debug this problem of the sudden crashes - but as I said:
even with all debug levels activated - slapd(8) didn't want to share its
root of the pain. This workaround was the only way I could use OpenLDAP
at all over the past five years.
Two days ago I got to the point where my workaround came to its capacity
boundary. The time between the slapd(8) crashes has become so little, so
my script can't handle them anylonger. I would have two options now:
a) Fix my supervisor script, so it detects and starts slapd(8) even if
the time between crashes is less than 3 sec.
b) I ask for help in order to discover this mysterious cause of the
crashes and FINALLY fix it FOREVER.
So this time I set my foot down and go for b). This is why I decided to
contact you. The following link containes a more detailed debugging of
the problem:
https://forums.freebsd.org/threads/openldap-slapd-dies-sporadically.47634/
And this is the current / latest configuration I deploy on my servers.
Also, it doesn't make a difference whether I have monitoring activated
or not. It keeps on dieing the same as before. The very same ocours to
the "ldapab.schema" - it doesn't make a difference for the crashes to
happen whether it is commented out or activated. Logging hapens through
syslogd(8).
# ============================================================ #
#======================================#
# slapd.conf #
#======================================#
# LDAP Attribut Schema Definitions:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/ldapab.schema
include /usr/local/etc/openldap/schema/mail.schema
#include /usr/local/etc/openldap/schema/qouta.schema
# Logging
loglevel 256
# If "logfile" is activated, then newsyslog must restart slapd after
rotation
#logfile /var/log/slapd.log
# Important Files
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Allow LDAPv2 client connections. This is required for iOS suppoprt via
SSL.
#allow bind_v2
# Time limits
#idletimeout 0
#writetimeout 0
#timelimit 3600
# Dynamic Modules:
modulepath /usr/local/libexec/openldap
moduleload back_mdb
moduleload back_monitor
# Access from 127.0.0.1 without encryption
access to dn.subtree="dc=MyDomain,dc=local"
by peername.ip=127.0.0.1 write
by * none break
# Access from other than 127.0.0.1 requires TLS
# encryption with min. 128 bit encryption
access to dn.subtree="dc=MyDomain,dc=local"
by ssf=128 write
by * none
# TLS-Certificate
TLSCertificateFile /etc/ssl/PKI/CA/Signing-CA/Certs/WM-01.MyDomain.Local.crt
TLSCertificateKeyFile
/etc/ssl/PKI/CA/Signing-CA/Private/WM-01.MyDomain.Local.key
TLSVerifyClient allow
# Restrict write access for password attributes to root user only
by dn="uid=dovecot,ou=systemuser,ou=mail,dc=MyDomain,dc=Local"
access to attrs=userPassword
by self write
by anonymous auth
by * none
# All the other atributes can be read by everyone else
access to *
by * read
# ================================== #
# Internal Monitoring #
# ================================== #
# DB type
database monitor
# Name of Administrator
rootdn "cn=monitoring,cn=Monitor"
# Password of Administrators
rootpw {SSHA}SomeHash
# ACL for moitoring
access to dn.subtree="cn=Monitor"
by dn.exact="cn=admin,dc=MyDomain,dc=local" write
by peername.ip=127.0.0.1 read
by users read
by * none
# ================================== #
# Lightning Memory-Mapped Database #
# ================================== #
# Datenbanktyp
database mdb
# DB location on FS
directory /var/db/openldap-data
# Datenbank-Pfad
suffix "dc=MyDomain,dc=local"
# Name of Administrator
rootdn "cn=admin,dc=MyDomain,dc=local"
# Password of Administrators
rootpw {SSHA}SomeHash
# Max size of DB in Byte [ 5368709120 Byte => 5 GB ]
maxsize 5368709120
# Index search related attributes
index objectClass eq
index uid eq
index uidNumber eq
index uniqueMember eq
index gidNumber eq
index cn eq
index memberUid eq
index mailAccountStatus eq
index mailAddress eq
index associatedDomain eq
# ============================================================= #
I compiled OpenLDAP from FreeBSD ports with following options:
- DYNAMIC_BACKENDS
- MDB
- PPOLICY
- SYNCPROV
- TCP_WRAPPERS
Please let me know what kind of further information I could deliver to
you in order to detect the root of the problem.
Thank you
Best regards
Leander
7 years, 10 months
uidNumber=4294967295 is being appearing in the log frequently
by Majid Khan
Dear Techies,
I'm not sure if this is the right forum to discuss this but I am getting the following from some of the clients machine I'm not sure why some of them sending this info otherwise my authentication and login all is working fine but I'm concern why its happening and my log is full of the following kind of message:
If this is not the right forum then I apologies and please direct me to that right group:
Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uidNumber=4294967295)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))"Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap
Server info: CentOS release 6.6LDAP version: openldap-2.4.40
Client info: CentOS release 6.2Client using SSSD: sssd-1.11.6
Thanks.
Best regards,
Majid.
7 years, 10 months
top object class contains all possible attributes?
by dE
From https://tools.ietf.org/html/rfc4512
it
can be said that an object class inherits the sets of *allowed* and
required attributes from its superclasses
Therefore the top object class contains all possible attributes? OR
A subclasses cannot contain any attribute which is not included in it's
superclass?
I'm running Apache directory studio, and I don't see that happening.
7 years, 10 months
Re: All entries belong to the top object class?
by dE
On 04/20/15 22:56, Michael Ströder wrote:
> dE wrote:
>> Does adding of the top object class (or
>> person) add all attributes to the entry?
>
> Nope. Which text in RFC 4512 leads to your presumption?
>
> Ciao, Michael.
>
>
Sorry for the late response. I was out of town.
From the responses, it appears the question has not been understood
correctly, I what I meant to ask was --
Does adding of the top object class (implicitly) make it possible to add
all attributes in the DIT to the entry? I'm talking about attributes
which are out of the 'MAY' in the most subordinate object class the
entry belong to.
7 years, 10 months
