at and cron vs. ldap SOLUTION!!

[Bevan C. Bennett]

Stephen Walton wrote:

> I'll be d****d.  That last line there was commented out and read
> #pam_filter objectclass=account

Eureka! Victory is ours!

> which I gather is the default.  Changing it to agree with your
> /etc/ldap.conf fixed the problem!  This didn't come up in the last
> version because, following the aforementioned OpenLDAP Everywhere
> article, my old LDIF's had both "objectclass=account" and
> "objectclass=posixAccount" for users.  The former apparently vanished
> from the inetorgperson.schema file somewhere between RH8 and FC1, and I
> removed it from my LDIF files in the transition.

There's still a generic 'account' objectClass in the 'cosine' schema.
It can become very useful if you update your openldap to the latest 
versions which now want to enforce the 'one and only one STRUCTURAL 
objectclass per object' rule that was glossed over before.

account is a fairly sparse STRUCTURAL class, while posixaccount and 
sambasamaccount are AUXILIARY. account doesn't add much, but it only 
requires 'userid', which you'll have from posixaccount anyway.


>>nss_base_passwd        ou=People,dc=domain,dc=com?one
>>nss_base_shadow        ou=People,dc=domain,dc=com?one
>>nss_base_group         ou=Groups,dc=domain,dc=com?one
> How necessary is this?  I've got my ou's set to "people" and "group"
> instead of "People" and "Groups" respectively.  Right now everything
> seems to work but who knows...I suppose I'd better change them too.

The defaults work fine for most. It's case insensitive, so there's 
difference between 'people' and 'People'. I changed from group to groups 
so that all of my top level containers can be plural (people, groups, 
computers, ...) but that's not at all mandatory.

Glad to help get your clients back on track!