[CentOS] ldif invalid per syntax
Tim Dunphy
bluethundr at gmail.com
Mon Oct 11 02:33:13 UTC 2010
someone reminded me that i was missing the posix account information I
needed i LDAP.
I have added the corresponding posix accounts in LDAP I wish to use:
12 uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
ou: staff
cn: Tim
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: bluethundr
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
userPassword: secret
gecos: Tim
13 cn=root,ou=staff,dc=summitnjhome,dc=com
ou: staff
cn: Enoch Root
cn: Root, Enoch
cn: root
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: root
uidNumber: 1
gidNumber: 1
homeDirectory: /root
userPassword: secret
gecos: Enoch Root
So tho anon search can work this more specific one used in ldap.conf
can in fact find the entries:
ldapsearch -x -h ldap -D
"cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -w secret -b
"dc=summitnjhome,dc=com"
# bluethundr, summitnjops, staff, summitnjhome.com
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
ou: staff
cn: Tim
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: bluethundr
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
gecos: Tim
# root, staff, summitnjhome.com
dn: cn=root,ou=staff,dc=summitnjhome,dc=com
ou: staff
cn: Enoch Root
cn: Root, Enoch
cn: root
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: root
uidNumber: 1
gidNumber: 1
homeDirectory: /root
gecos:: RW5vY2ggUm9vdCA=
Yet su to these accounts is still broken:
[bluethundr at LCEN0T02:~]$:su - root
Password:
Last login: Sun Oct 10 14:57:29 on pts/9
logging in slapd.conf has been set to 256
loglevel 256
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
syslog.conf has been told to log openldap errors to /var/log/openldap.log
local4.* /var/log/openldap.log
[root at LCEN0T02:/usr/local/etc/openldap]#tail -f /var/log/openldap.log
Oct 11 02:12:44 LCEN0T02 slapd[42790]: conn=1000 op=1 RESULT tag=97 err=49 text=
Oct 11 02:12:44 LCEN0T02 slapd[42790]: conn=1000 op=2 UNBIND
Oct 11 02:12:44 LCEN0T02 slapd[42790]: conn=1000 fd=11 closed
Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 fd=11 ACCEPT from
IP=127.0.0.1:60289 (IP=0.0.0.0:389)
Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=0 BIND
dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=0 RESULT tag=97 err=49 text=
Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=1 BIND
dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=1 RESULT tag=97 err=49 text=
Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=2 UNBIND
Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 fd=11 closed
this is what is going on in the message logs:
Oct 11 02:12:44 LCEN0T02 su: pam_ldap: error trying to bind (Invalid
credentials)
Oct 11 02:12:44 LCEN0T02 su: pam_ldap: error trying to bind (Invalid
credentials)
Oct 11 02:12:44 LCEN0T02 su: in _openpam_check_error_code():
pam_sm_acct_mgmt(): unexpected return value 11
Any idea why su _still_ isn't authenticating even tho the user
accounts have been added to LDAP??? :::sigh:::
On Sat, Oct 9, 2010 at 4:36 PM, Tim Dunphy <bluethundr at gmail.com> wrote:
> 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 at 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 at 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 at 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 at 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!!
>
--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
More information about the CentOS
mailing list