LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices



Reply
 
Search this Thread
Old 11-04-2010, 03:43 PM   #1
bluethundr
Member
 
Registered: Jun 2003
Location: Summit, NJ
Distribution: CentOS 5.4
Posts: 122

Rep: Reputation: 15
Post ldif fails to import into ldap


Thanks all.. I have read the man of ldif.... your advice has gotten me quite far both in my current implementation and in my overall understanding of LDAP which I am hoping grows with each passing day.

In my attempt to build my current directory, I have taken a dump of my last successful implementation (which was created on FreeBSD 8.1) and substituted values for the dc=company and dc=com values with the correct ones for the current directory (attempting to implement under CentOS 5.4) and even tho the correct schemas are in place it is choking on this entry:

Code:
# defaults, sudoers, Services, acadaca.com
dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
And again I should have all the schemas in place to make this work...

Code:
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/misc.schema
inlcude         /etc/openldap/schema/sudoers.schema
include         /etc/openldap/schema/openldap.schema
Code:
[root@ldap ldif]# ldapadd -h ldap -a -w secret -x -D "cn=Manager,dc=acadaca,dc=net" -f /home/tim/txt/ldif/acadaca-master.ldif 
adding new entry "cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net"
ldapadd: Invalid syntax (21)
	additional info: objectClass: value #1 invalid per syntax
This is what is going on in the openldap logs:

Code:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 busy
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: listen=7, new connection on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: added 12r (active) listener=(nil)
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 ACCEPT from IP=10.203.49.140:51779 (IP=0.0.0.0:389)
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:  12r
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" method=128
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" mech=SIMPLE ssf=0
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 RESULT tag=97 err=0 text=
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:  12r
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 ADD dn="cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net"
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 RESULT tag=105 err=21 text=objectClass: value #1 invalid per syntax
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:  12r
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=2 UNBIND
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: removing 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 closed
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: 
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Why this ldif will work in one directory but not another is a mystery at this point..

thanks again

Last edited by bluethundr; 11-04-2010 at 04:01 PM. Reason: added logging info
 
Old 11-04-2010, 09:07 PM   #2
kbp
Senior Member
 
Registered: Aug 2009
Posts: 3,758

Rep: Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644
Hmm .. does the sudoRole class exist in /etc/openldap/schema/sudoers.schema ?
 
Old 11-05-2010, 10:27 AM   #3
bluethundr
Member
 
Registered: Jun 2003
Location: Summit, NJ
Distribution: CentOS 5.4
Posts: 122

Original Poster
Rep: Reputation: 15
Question sudoRole not working in openldap 2.3

Quote:
Originally Posted by kbp View Post
Hmm .. does the sudoRole class exist in /etc/openldap/schema/sudoers.schema ?
Hi there! Why yes, in fact it does!

From /etc/openldap/shcema/sudoers.schema on the CentOS 5.4 box:

Code:
objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
    DESC 'Sudoer Entries'
    MUST ( cn )
    MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $
            description )
    )
This schema was rsync'd from a FreeBSD implementation where sudoRole attribute works. The only thing that comes to mind presently is that there are different versions running on the working implementation (FreeBSD 8.1) and on the non working version (CentOS 5.4).

On the Centos box I am running version 2.3:

Code:
[root@ldap schema]# slapd -V
@(#) $OpenLDAP: slapd 2.3.43 (Aug 11 2010 09:09:21) $
	mockbuild@builder17.centos.org:/builddir/build/BUILD/openldap-2.3.43/openldap-2.3.43/build-servers/servers/slapd
But on the FreeBSD box I am running version 2.4:

Code:
[root@LBSD2:/usr/home/bluethundr]#slapd -V
@(#) $OpenLDAP: slapd 2.4.23 (Oct  9 2010 21:36:56) $
	root@LBSD2.summitnjhome.com:/usr/ports/net/openldap24-server/work/openldap-2.4.23/servers/slapd
Do you think the problem could stem from the fact that these are different versions? If so, do you have any suggestion for how I can get sudoRole working under 2.3?

Thanks again
 
Old 11-05-2010, 12:35 PM   #4
kbp
Senior Member
 
Registered: Aug 2009
Posts: 3,758

Rep: Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644
Possibly ... did you restart slapd after including the sudo.schema file ?
 
Old 11-10-2010, 12:06 AM   #5
bluethundr
Member
 
Registered: Jun 2003
Location: Summit, NJ
Distribution: CentOS 5.4
Posts: 122

Original Poster
Rep: Reputation: 15
Red face problem found.. onto pam / ldap?

Quote:
Originally Posted by kbp View Post
Possibly ... did you restart slapd after including the sudo.schema file ?
Greetings.. sorry for the delay in following up on this. I actually did find the problem.... it was this line:

Code:
inlcude         /etc/openldap/schema/sudoers.schema
Which should have read:

Code:
include         /etc/openldap/schema/sudoers.schema
Yes!! That's right!! A simple type-o ruined that day!! heh..

At any rate, I am attempting to solve another problem and I was hoping that someone might have some insight into what is going on here..

At this point my LDAP server is working quite splendidly!

I have a working directory with users able to authenticate it and TLS turned on and it is ALL happening through PAM!! Well almost all of it..

The one sticking point I am currently having is getting sudoers to authenticate against LDAP.

Both client and server are CentOS 5.4. On the client I have my /etc/ldap.conf file setup like this:

Code:
URI ldap://ldap.acadaca.net/
BASE dc=acadaca,dc=net
TLS_CACERTDIR /etc/openldap/cacerts
pam_login_attribute     uid
pam_lookup_policy       yes
pam_password            exop
nss_base_passwd         ou=staff,dc=acadaca,dc=net
sudoers_debug 2
I have added the user I am testing to a couple of groups (two regular
DNs and one posixGroup) all of which had the sudoRole objectClass in
the hopes that this might be related to the issue:

Code:
46 cn=%sa,ou=sudoers,ou=Services,dc=acadaca,dc=net
objectClass: top
objectClass: sudoRole
cn: %sa
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate
sudoUser: %sa
sudoUser: bluethundr


50 cn=role1,ou=sudoers,ou=Services,dc=acadaca,dc=net
objectClass: sudoRole
objectClass: top
cn: role1
sudoUser: bluethundr
sudoHost: ALL
sudoCommand: ALL

51 cn=sa,ou=Group,dc=acadaca,dc=net
objectClass: posixGroup
objectClass: top
cn: sa
userPassword: {crypt}*
gidNumber: 20004
However that didn't seem to do the trick. When I do attempt to sudo from the client machine this is what I see on the command line:

Code:
[bluethundr@VIRCENT03:~]#sudo bash
[sudo] password for bluethundr:
bluethundr is not in the sudoers file.  This incident will be reported.
[bluethundr@VIRCENT03:~]#sudo -l
[sudo] password for bluethundr:
Sorry, user bluethundr may not run sudo on VIRCENT03.
Also I notice that the client can't seem to find it's groups stored in
LDAP even tho I would think that system auth would point sudoers
to them just as it does sshd and su.

Code:
[bluethundr@VIRCENT03:~]#groups bluethundr
id: cannot find name for group ID 1002
I am not entirely sure that this is a separate issue, honestly but I think it may be related.


The other pam services I am working with, su and sshd, trigger events in the openldap logs on the server. Everything is going smoothly with these services, apparently:

In the openldap logs on the server here is a sample of what I see:

Code:
Nov  9 14:03:56 ldap slapd[31269]: bdb_search_candidates: id=1 first=54 last=54
Nov  9 14:03:56 ldap slapd[31269]: => test_filter
Nov  9 14:03:56 ldap slapd[31269]:     AND
Nov  9 14:03:56 ldap slapd[31269]: => test_filter_and
Nov  9 14:03:56 ldap slapd[31269]: => test_filter
Nov  9 14:03:56 ldap slapd[31269]:     EQUALITY
Nov  9 14:03:56 ldap slapd[31269]: => access_allowed: search access to
"uid=bluethundr,ou=sa,ou=staff,dc=acadaca,dc=net" "objectClass"
requested
Nov  9 14:03:56 ldap slapd[31269]: => acl_get: [1] attr objectClass
Nov  9 14:03:56 ldap slapd[31269]: => acl_mask: access to entry
"uid=bluethundr,ou=sa,ou=staff,dc=acadaca,dc=net", attr "objectClass"
requested
Nov  9 14:03:56 ldap slapd[31269]: => acl_mask: to value by "", (=0)
Nov  9 14:03:56 ldap slapd[31269]: <= acl_mask: [1] applying read(=rscxd) (stop)
Nov  9 14:03:56 ldap slapd[31269]: <= acl_mask: [1] mask: read(=rscxd)
Nov  9 14:03:56 ldap slapd[31269]: => access_allowed: search access
granted by read(=rscxd)
I've attached a more complete log file that shows a little more context. What I've done was clear the openldap logs with an echo " " > statement just before sudoing to root on the client. And the attached logs are show what happened after the event. Honestly, I wish I was better at parsing these log files but unfortunately I'm not quite there as of yet.

Back on the client side I see this noticeable event, amongst quite a lot of successful pam events in the secure log:

Code:
Nov  9 15:37:39 VIRCENT03 sudo: bluethundr : user NOT in sudoers ;
TTY=pts/3 ; PWD=/home/bluethundr ; USER=root ; COMMAND=/bin/bash
I've also attached a more complete secure log showing a bit more context.

And lastly I've included a copy of my schema in the hopes that that may help.

Thanks again for any input you may have.
Attached Files
File Type: txt sercurelogs.txt (1.9 KB, 1 views)
File Type: txt schema-11-09-10.txt (17.9 KB, 2 views)
File Type: txt openldap.txt (229.5 KB, 1 views)
 
Old 11-10-2010, 06:32 PM   #6
kbp
Senior Member
 
Registered: Aug 2009
Posts: 3,758

Rep: Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644
The output of 'getent group' should include your ldap groups, BTW your /etc/ldap.conf contents look like they should belong in /etc/openldap/ldap.conf, these files are used by different processes - ref: http://www.openldap.org/lists/openld.../msg00336.html

hth
 
Old 11-10-2010, 06:55 PM   #7
bluethundr
Member
 
Registered: Jun 2003
Location: Summit, NJ
Distribution: CentOS 5.4
Posts: 122

Original Poster
Rep: Reputation: 15
Post getent output

Quote:
Originally Posted by kbp View Post
The output of 'getent group' should include your ldap groups, BTW your /etc/ldap.conf contents look like they should belong in /etc/openldap/ldap.conf, these files are used by different processes - ref: http://www.openldap.org/lists/openld.../msg00336.html

hth
Thanks for the tip! I've noticed that if the first three lines of my ldap.conf file are removed all of pam ceases to function. When I put them back pam works again. I am actually aware of the difference between /etc/ldap.conf and /etc/openldap/ldap.conf but I will be sure to read the link you have provided.

In the meantime, this is what I see when I type getent groups:

Code:
[bluethundr@LCENT01:~]#getent groups
Unknown database: groups
Try `getent --help' or `getent --usage' for more information.
 
Old 11-10-2010, 07:15 PM   #8
kbp
Senior Member
 
Registered: Aug 2009
Posts: 3,758

Rep: Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644
try 'group' not 'groups'
 
Old 11-10-2010, 07:19 PM   #9
bluethundr
Member
 
Registered: Jun 2003
Location: Summit, NJ
Distribution: CentOS 5.4
Posts: 122

Original Poster
Rep: Reputation: 15
Red face corrected getent group

Quote:
Originally Posted by kbp View Post
try 'group' not 'groups'
Sorry for the type-o...

here's the output of the correct command:

Code:
[bluethundr@LBSD2:~]#ssh sum1
Last login: Wed Nov 10 19:00:38 2010 from 192.168.1.44
#########################################################
#               SUMMITNJHOME.COM                        #
#               TITLE:       LCENT01 BOX                #
#               LOCATION:    SUMMIT BASEMENT            #
#                                                       #
#########################################################


[bluethundr@LCENT01:~]#getent group
root::0:root
bin::1:root,bin,daemon
daemon::2:root,bin,daemon
sys::3:root,bin,adm
adm::4:root,adm,daemon
tty::5:
disk::6:root
lp::7:daemon,lp
mem::8:
kmem::9:
wheel::10:root
mail::12:mail
news::13:news
uucp::14:uucp
man::15:
games::20:
gopher::30:
dip::40:
ftp::50:
lock::54:
nobody::99:
users::100:
utmp:x:22:
utempter:x:35:
nscd:x:28:
distcache:x:94:
ais:x:39:
floppy:x:19:
vcsa:x:69:
pcap:x:77:
slocate:x:21:
audio:x:63:gdm
apache:x:48:
rpc:x:32:
mailnull:x:47:
smmsp:x:51:
ntp:x:38:
ecryptfs:x:101:
piranha:x:60:
webalizer:x:67:
dovecot:x:97:
squid:x:23:
luci:x:102:
named:x:25:
hsqldb:x:96:
sshd:x:74:
dbus:x:81:
avahi:x:70:
xfs:x:43:
summitnjops:x:1002:
rpcuser:x:29:
nfsnobody:x:4294967294:
pegasus:x:65:
ricci:x:103:
haldaemon:x:68:
avahi-autoipd:x:104:
gdm:x:42:
sabayon:x:86:
nx:!:390:
ldapuser:crYxLlVfym.Ho:1004:
wheel:*:0:root

This looks like the local /etc/group file to me, not the one I have in LDAP.
 
Old 11-10-2010, 08:11 PM   #10
kbp
Senior Member
 
Registered: Aug 2009
Posts: 3,758

Rep: Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644
If it's not working then you'll need to check your ldap.conf's
 
  


Reply

Tags
openldap


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how can i import base.ldif into my database dezio Linux - Server 1 09-09-2010 05:24 PM
Getting a "Can't contact LDAP server" when trying to add an ldif file custangro Linux - Server 4 09-04-2008 02:00 PM
Problem ldif file for ldap finsh Linux - Server 5 01-15-2008 12:16 PM
admin.ldif for ldap berrance Linux - Networking 1 03-06-2005 06:32 AM
New to Open LDAP. Trying to import an LDIF file. davealex Linux - Networking 1 10-16-2003 04:19 PM


All times are GMT -5. The time now is 03:57 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration