Well, if I'm not mistaken copying this file to my shchema directory and referencing it in my slapd.conf file should have taken care of this objectClass:

cp /usr/local/share/doc/sudo/schema.OpenLDAP /usr/local/etc/openldap/schema/openldap.schema

And, as mentioned, I made sure to include this in my slapd.conf file:

# See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # 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/openldap.schema

The _last_ thing I added to my ldap database was this entry (using ldapvi)

# sudoers, Services, summitnjhome.com dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com ou: sudoers objectClass: organizationalUnit

I then set the appropriate environment variable (I'm partial to C Shell these days):

setenv SUDOERS_BASE ou=sudoers,ou=Services,dc=summitnjhome,dc=com

And exported my sudoers list to an ldif file using this command:

/usr/local/share/doc/sudo/sudoers2ldif /usr/local/etc/sudoers > /home/bluethundr/txt/ldif/sudoers.ldif

And that is when I run into the error that I described earlier:

LBSD2# ldapadd -h ldap -a -W -x -D "cn=Manager,dc=summitnjhome,dc=com" -f /home/bluethundr/txt/ldif/sudoers.ldif Enter LDAP Password: adding new entry "cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com" ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax

For refresher, this is the entry it's having trouble with:

dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here

As far as I can gather, sudoRole (which is where the problem appears to lie) was supposed to have been added along with the openldap.schema that I've included in my slapd.conf file.

Thanks for the help so far...

On Thu, Oct 7, 2010 at 5:05 PM, Scott Robbins scottro@nyc.rr.com wrote:

On Thu, Oct 07, 2010 at 04:38:42PM -0400, Tim Dunphy wrote:

...

Hello CentOS

I am having a bit of trouble importing an ldif into openldap, tho the syntax looks a-ok to me. I am attempting to import my sudoers list into my ldap configuration and I used an application called sudoers2ldif to generate the ldif.

I used the following command to import the file:

=============================================

[root@bluethundr-desktop:~/txt/ldif ] $:ldapadd -h ldap -a -W -x -D "cn=Manager,dc=summitnjhome,dc=com" -f /home/bluethundr/txt/sudoers2.ldif Enter LDAP Password: adding new entry "cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com" ldap_add: Invalid syntax (21)        additional info: objectClass: value #1 invalid per syntax

It indicates that the second line (it counts from 0, so #1 should be the second line) has something wrong.  I would think you'd have to put the objectclass of sudoRole in a schema--a quick look at your email doesn't show it there--forgive me if I missed it.

Errm, that is, second line of your objectclass.  It makes sense.

Taking just the object class listing.

...

objectClass: top objectClass: sudoRole

We see that value #1 is sudoRole.  I don't see it defined in your schema, forgive me if I missed it.   If I'm correct though, and it's not in your schema, that's your problem.

(Not sure if I should snip the rest of this or not, so will be conservative and not snip--for anyone following the thread, this sentence ends what I have to say about it.  :)

...

=============================================

And this is the file I am trying to import sudoers2.ldif:

============================================

dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here

dn: cn=root,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: root sudoUser: root sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL

dn: cn=%wheel,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: %wheel sudoUser: %wheel sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOption: !authenticate

dn: cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: %summitnjops sudoUser: %summitnjops sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOption: !authenticate

======================================================

my ldap schema looks like so:

====================================================== Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=summitnjhome,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #

# summitnjhome.com dn: dc=summitnjhome,dc=com dc: summitnjhome objectClass: dcObject objectClass: organization o: Summit NJ Home

# staff, summitnjhome.com dn: ou=staff,dc=summitnjhome,dc=com ou: staff objectClass: organizationalUnit

# summitnjops, staff, summitnjhome.com dn: ou=summitnjops,ou=staff,dc=summitnjhome,dc=com ou: summitnjops objectClass: organizationalUnit

# people, summitnjhome.com dn: ou=people,dc=summitnjhome,dc=com ou: customers ou: people objectClass: organizationalUnit

# Services, summitnjhome.com dn: ou=Services,dc=summitnjhome,dc=com ou: services objectClass: organizationalUnit

# pam_ldap, Services, summitnjhome.com dn: cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com cn: pam_ldap objectClass: top objectClass: inetOrgPerson sn: PAM userPassword:: secretPass

# sudoers, Services, summitnjhome.com dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com ou: sudoers objectClass: organizationalUnit

# search result search: 2 result: 0 Success

# numResponses: 8 # numEntries: 7

==============================================================

could someone please suggest how to get around this error?

thanks!

Tim _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

I just recopied openLDAP.schema as sudoers.schema and added it to slapd.conf

[bluethundr@bluethundr-desktop:~/txt/ldif ] $:ldapadd -h ldap -a -W -x -D "cn=Manager,dc=summitnjhome,dc=com" -f /home/bluethundr/txt/sudoers2.ldif Enter LDAP Password: adding new entry "cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com"

adding new entry "cn=root,ou=sudoers,ou=Services,dc=summitnjhome,dc=com"

adding new entry "cn=%wheel,ou=sudoers,ou=Services,dc=summitnjhome,dc=com"

adding new entry "cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com"

MAJOR WIN and THANKS to scott !!!

On Fri, Oct 8, 2010 at 9:36 PM, Tim Dunphy bluethundr@gmail.com wrote:

hmm.. it would seem that grepping the shcema directory for sudoRole or sudo anything doesn't turn up anything...

[root@LCENT01:/usr/local/etc/openldap]#grep -ri sudoRole /usr/local/etc/openldap/schema/ [root@LCENT01:/usr/local/etc/openldap]#grep -ri sudo /usr/local/etc/openldap/schema/ [root@LCENT01:/usr/local/etc/openldap]#

On Thu, Oct 7, 2010 at 9:31 PM, Tim Dunphy bluethundr@gmail.com wrote:

...

Well, if I'm not mistaken copying this file to my shchema directory and referencing it in my slapd.conf file should have taken care of this objectClass:

cp /usr/local/share/doc/sudo/schema.OpenLDAP /usr/local/etc/openldap/schema/openldap.schema

And, as mentioned, I made sure to include this in my slapd.conf file:

# See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # 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/openldap.schema

The _last_ thing I added to my ldap database was this entry (using ldapvi)

# sudoers, Services, summitnjhome.com dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com ou: sudoers objectClass: organizationalUnit

I then set the appropriate environment variable  (I'm partial to C Shell these days):

setenv SUDOERS_BASE ou=sudoers,ou=Services,dc=summitnjhome,dc=com

And exported my sudoers list to an ldif file using this command:

/usr/local/share/doc/sudo/sudoers2ldif /usr/local/etc/sudoers > /home/bluethundr/txt/ldif/sudoers.ldif

And that is when I run into the error that I described earlier:

LBSD2# ldapadd -h ldap -a -W -x -D "cn=Manager,dc=summitnjhome,dc=com" -f /home/bluethundr/txt/ldif/sudoers.ldif Enter LDAP Password: adding new entry "cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com" ldap_add: Invalid syntax (21)        additional info: objectClass: value #1 invalid per syntax

For refresher, this is the entry it's having trouble with:

dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here

As far as I can gather, sudoRole (which is where the problem appears to lie) was supposed to have been added along with the openldap.schema that I've included in my slapd.conf file.

Thanks for the help so far...

On Thu, Oct 7, 2010 at 5:05 PM, Scott Robbins scottro@nyc.rr.com wrote:

...

On Thu, Oct 07, 2010 at 04:38:42PM -0400, Tim Dunphy wrote:

...

Hello CentOS

I am having a bit of trouble importing an ldif into openldap, tho the syntax looks a-ok to me. I am attempting to import my sudoers list into my ldap configuration and I used an application called sudoers2ldif to generate the ldif.

I used the following command to import the file:

=============================================

[root@bluethundr-desktop:~/txt/ldif ] $:ldapadd -h ldap -a -W -x -D "cn=Manager,dc=summitnjhome,dc=com" -f /home/bluethundr/txt/sudoers2.ldif Enter LDAP Password: adding new entry "cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com" ldap_add: Invalid syntax (21)        additional info: objectClass: value #1 invalid per syntax

It indicates that the second line (it counts from 0, so #1 should be the second line) has something wrong.  I would think you'd have to put the objectclass of sudoRole in a schema--a quick look at your email doesn't show it there--forgive me if I missed it.

Errm, that is, second line of your objectclass.  It makes sense.

Taking just the object class listing.

...

objectClass: top objectClass: sudoRole

We see that value #1 is sudoRole.  I don't see it defined in your schema, forgive me if I missed it.   If I'm correct though, and it's not in your schema, that's your problem.

(Not sure if I should snip the rest of this or not, so will be conservative and not snip--for anyone following the thread, this sentence ends what I have to say about it.  :)

...

=============================================

And this is the file I am trying to import sudoers2.ldif:

============================================

dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here

dn: cn=root,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: root sudoUser: root sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL

dn: cn=%wheel,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: %wheel sudoUser: %wheel sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOption: !authenticate

dn: cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: %summitnjops sudoUser: %summitnjops sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOption: !authenticate

======================================================

my ldap schema looks like so:

====================================================== Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=summitnjhome,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #

# summitnjhome.com dn: dc=summitnjhome,dc=com dc: summitnjhome objectClass: dcObject objectClass: organization o: Summit NJ Home

# staff, summitnjhome.com dn: ou=staff,dc=summitnjhome,dc=com ou: staff objectClass: organizationalUnit

# summitnjops, staff, summitnjhome.com dn: ou=summitnjops,ou=staff,dc=summitnjhome,dc=com ou: summitnjops objectClass: organizationalUnit

# people, summitnjhome.com dn: ou=people,dc=summitnjhome,dc=com ou: customers ou: people objectClass: organizationalUnit

# Services, summitnjhome.com dn: ou=Services,dc=summitnjhome,dc=com ou: services objectClass: organizationalUnit

# pam_ldap, Services, summitnjhome.com dn: cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com cn: pam_ldap objectClass: top objectClass: inetOrgPerson sn: PAM userPassword:: secretPass

# sudoers, Services, summitnjhome.com dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com ou: sudoers objectClass: organizationalUnit

# search result search: 2 result: 0 Success

# numResponses: 8 # numEntries: 7

==============================================================

could someone please suggest how to get around this error?

thanks!

Tim _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

Share and enjoy!!

Hey guys!

Unfortunately I have a new wrinkle. While I certainly got to make my sudoers work through LDAP (thanks to those who helped) unfortunately PAM is unhappy at the moment.

So, while sudo is working in ldap, for any of the services that need to authenticate through pam (i.e. ssh and su) it is still a no-go. I am getting pam authentication errors in my log files.

But LDAP is certainly doing it's job!

Using the account I have setup in LDAP as the pam user I can search my base DN:

[bluethundr@bluethundr-desktop:~ ] $:ldapsearch -x -h ldap -D "cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -w secret -b "dc=summitnjhome,dc=com" # extended LDIF # # LDAPv3 # base <dc=summitnjhome,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #

# summitnjhome.com dn: dc=summitnjhome,dc=com dc: summitnjhome objectClass: dcObject objectClass: organization o: Summit NJ Home

# staff, summitnjhome.com dn: ou=staff,dc=summitnjhome,dc=com ou: staff objectClass: organizationalUnit

# summitnjops, staff, summitnjhome.com dn: ou=summitnjops,ou=staff,dc=summitnjhome,dc=com ou: summitnjops objectClass: organizationalUnit

# people, summitnjhome.com dn: ou=people,dc=summitnjhome,dc=com objectClass: organizationalUnit ou: people

# Services, summitnjhome.com dn: ou=Services,dc=summitnjhome,dc=com ou: services objectClass: organizationalUnit

# pam_ldap, Services, summitnjhome.com dn: cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com cn: pam_ldap objectClass: top objectClass: inetOrgPerson sn: PAM userPassword:: e1NTSEF9K2NsWktBUXVDWEhkbjVBcVRDbFVMb0ROZVcvelltelIg

# sudoers, Services, summitnjhome.com dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com ou: sudoers objectClass: organizationalUnit

# defaults, sudoers, Services, summitnjhome.com dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here

# root, sudoers, Services, summitnjhome.com dn: cn=root,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: root sudoUser: root sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL

# %wheel, sudoers, Services, summitnjhome.com dn: cn=%wheel,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: %wheel sudoUser: %wheel sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOption: !authenticate

# %summitnjops, sudoers, Services, summitnjhome.com dn: cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: %summitnjops sudoUser: %summitnjops sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOption: !authenticate

# search result search: 2 result: 0 Success

# numResponses: 12 # numEntries: 11

And this is the entry I have in my LDAP database for the pam_ldap user:

5 cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com cn: pam_ldap objectClass: top objectClass: inetOrgPerson sn: PAM userPassword: secret

So far so good, everything works.

However, this is how I have my ldap.conf file setup:

host ldap.summitnjhome.com base dc=summitnjhome,dc=com binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com bindpw secret scope sub pam_password exop nss_base_passwd ou=staff,dc=summitnjhome,dc=com nss_base_shadow ou=staff,dc=summitnjhome,dc=com

( I have also tried setting the host to 127.0.0.1 as well, with no joy)

And observe what happens if I try to su using pam/ldap

Oct 9 20:25:11 LCENT01 su: pam_ldap: error trying to bind (Invalid credentials) Oct 9 20:25:11 LCENT01 su: pam_ldap: error trying to bind (Invalid credentials) Oct 9 20:25:11 LCENT01 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11 Oct 9 20:25:11 LCENT01 su: bluethundr to root on /dev/pts/0

ssh has roughly the same effect on the logs but in order for me to demonstrate that I would likely have to gain physical access to the box to fix it. So hopefully the above example will suffice.

This is how my pam su file is configured:

LCENT01# cat /etc/pam.d/su # # System-wide defaults #

# auth auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth sufficient pam_ldap.so auth required pam_unix.so no_warn try_first_pass nullok

# account #account required pam_krb5.so account required pam_login_access.so account sufficient pam_ldap.so account required pam_unix.so

# session #session optional pam_ssh.so session required pam_ldap.so session required pam_lastlog.so no_fail

# password #password sufficient pam_krb5.so no_warn try_first_pass password required pam_unix.so no_warn try_first_pass

I assume that whatever is breaking su is breaking ssh. Does anyone have any ideas as to why slapd cannot access the pam_ldap account user automatically through /usr/local/etc/ldap.conf? x(

On Fri, Oct 8, 2010 at 11:01 PM, Scott Robbins scottro@nyc.rr.com wrote:

On Fri, Oct 08, 2010 at 10:52:54PM -0400, Tim Dunphy wrote:

...

I just recopied openLDAP.schema as sudoers.schema and added it to slapd.conf

[bluethundr@bluethundr-desktop:~/txt/ldif ] $:ldapadd -h ldap -a -W -x -D "cn=Manager,dc=summitnjhome,dc=com" -f /home/bluethundr/txt/sudoers2.ldif adding new entry "cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com"

<snip> > > MAJOR WIN and THANKS to scott !!!

Glad you got it sorted and you're more than welcome.

-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Buffy: Oh, look at my poor neck... all bare and tender and exposed. All that blood, just pumping away. Giles: Oh, please. Spike: Giles, make her stop! Giles: If those two don't kill each other, I might lend a hand.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

I have added the corresponding posix accounts in LDAP I wish to use:

Here is a LDIF snippet that works for users authenticated via LDAP:

dn: uid=myuser,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top cn: FirstName LastName gidNumber: 1130 homeDirectory: /home/myuser sn: LastName uid: myuser uidNumber: 1130 gecos: FirstName LastName givenName: FirstName loginShell: /bin/bash mail: myuser@example.com userPassword:: *******************************************************

dn: uid=myuser,ou=Group,dc=example,dc=com objectClass: posixGroup objectClass: top cn: myuser gidNumber: 1130

Yet su to these accounts is still broken:

I would recommend you to (maybe you have done some already):

- check your ACLs in slpad.conf, quite a few fields need to be visible when doing anonymous binds: http://www.openldap.org/lists/openldap-software/200208/msg00855.html (you may want to add or remove some depending on what you want to achieve, but first try a loose configuration, in order to have something working)

- use a simple, "standard", structure: ou=People,dc=example,dc=com ou=Group,dc=example,dc=com

- use authconfig to generate the configs (it will update pam, nss, and various ldap.conf), you can then review them and deploy them as files, although I have found that running the command is the most predictable way to replicate a working config on client systems

authconfig --enableldap --enableldapauth --enablecache --enablemkhomedir --ldapserver=ldap://myhost --ldapbasedn=dc=example,dc=com --passalgo=sha256 --updateall

- test all this on a separate clean environment (typically a virtual machine, before deploying it)

- maybe use the scripts in /usr/share/openldap/migration for your first import

Any idea why su _still_ isn't authenticating even tho the user accounts have been added to LDAP??? :::sigh:::

Getting this to work was long and painful for me, but worth the effort. Good luck.