On Wed, Oct 17, 2012 at 2:26 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Rich Megginson wrote:
>
>> On 10/17/2012 12:49 PM, Macklin, Jason wrote:
>>
>>> ldapsearch -xLLL -H 
>>> ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D 
>>> "cn=directory
>>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*
>>>
>> <snip>
>>
>>>
>>> dn: uid=asteinfeld,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>>
>> ...snip...
>>
>>> krbPrincipalName: asteinf...@dbr.roche.com
>>> krbPasswordExpiration: 20130324201805Z
>>> krbLastPwdChange: 20120925201805Z
>>> krbLoginFailedCount: 0
>>> krbLastSuccessfulAuth: 20121017184614Z
>>> krbTicketFlags: 128
>>> krbLastFailedAuth: 20121015143818Z
>>>
>>
>> No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
>> this means the "Entry permanently locked".  Not sure why.
>>
>
> I don't believe this applies if the attribute doesn't exist. It doesn't
> for any of my test users and it works fine.
>
>
>
>>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H
>>> ldap://dbduvdu145.dbr.roche.**com <http://dbduvdu145.dbr.roche.com> -D
>>> "cn=directory manager" -W -b
>>> "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password:
>>> dn: uid=jmacklin,cn=users,cn=**compat,dc=dbr,dc=roche,dc=com
>>> objectClass: posixAccount
>>> objectClass: top
>>> gecos: Jason Macklin
>>> cn: Jason Macklin
>>> uidNumber: 2084
>>> gidNumber: 2084
>>> loginShell: /bin/bash
>>> homeDirectory: /home2/jmacklin
>>> uid: jmacklin
>>>
>>> dn: uid=jmacklin,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>> displayName: Jason Macklin
>>> cn: Jason Macklin
>>> objectClass: top
>>> objectClass: person
>>> objectClass: organizationalperson
>>> objectClass: inetorgperson
>>> objectClass: inetuser
>>> objectClass: posixaccount
>>> objectClass: krbprincipalaux
>>> objectClass: krbticketpolicyaux
>>> objectClass: ipaobject
>>> objectClass: mepOriginEntry
>>> loginShell: /bin/bash
>>> sn: Macklin
>>> gecos: Jason Macklin
>>> homeDirectory: /home2/jmacklin
>>> krbPwdPolicyReference:
>>> cn=global_policy,cn=DBR.ROCHE.**COM <http://DBR.ROCHE.COM>
>>> ,cn=kerberos,dc=dbr,dc
>>>   =roche,dc=com
>>> krbPrincipalName: jmack...@dbr.roche.com
>>> givenName: Jason
>>> uid: jmacklin
>>> initials: JM
>>> uidNumber: 2084
>>> gidNumber: 2084
>>> ipaUniqueID: 045652b4-8e3c-11e1-831f-**005056bb0010
>>> mepManagedEntry: cn=jmacklin,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=
>>> **com
>>> memberOf: cn=admins,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>> memberOf: cn=Replication
>>> Administrators,cn=privileges,**cn=pbac,dc=dbr,dc=roche,
>>>   dc=com
>>> memberOf: cn=Add Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=roche
>>>   ,dc=com
>>> memberOf: cn=Modify Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro
>>>   che,dc=com
>>> memberOf: cn=Remove Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro
>>>   che,dc=com
>>> memberOf: cn=Host Enrollment,cn=privileges,cn=**
>>> pbac,dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Manage host
>>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Enroll a host,cn=permissions,cn=pbac,**
>>> dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Add krbPrincipalName to a
>>> host,cn=permissions,cn=pbac,**dc=dbr,dc=r
>>>   oche,dc=com
>>> memberOf: cn=Unlock user
>>> accounts,cn=permissions,cn=**pbac,dc=dbr,dc=roche,dc=co
>>>   m
>>> memberOf: cn=Manage service
>>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=c
>>>   om
>>> memberOf: cn=dbr,cn=groups,cn=accounts,**dc=dbr,dc=roche,dc=com
>>> memberOf:
>>> ipaUniqueID=23216c12-9934-**11e1-bd4c-005056bb0010,cn=**sudorules,cn=sud
>>>   o,dc=dbr,dc=roche,dc=com
>>> krbLastFailedAuth: 20121017164159Z
>>> krbPrincipalKey::
>>> MIIC4qADAgEBoQMCAQGiAwIBBaMDAg**EBpIICyjCCAsYwbaAgMB6gAwIBAKEX
>>>
>>> BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW**6hSTBHoAMCARKhQAQ+**
>>> IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
>>>
>>>
>>> sC2QJFL/**lnbaFO1DYG15WjJYXnJ7k3m0LN0aTy**jvz7FN4OWMF4tvvowXaAgMB6gAwIBA
>>> **KEXBBVEQl
>>>
>>>
>>> IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3**oAMCARGhMAQuEAD6UdNSe/**
>>> mp8qqi4OuT7HOqIs80DFQDRny
>>>
>>>
>>> 37aZaD4lYrFsnQiBtpnpMnNSxADBlo**CAwHqADAgEAoRcEFURCUi5ST0NIRS5**
>>> DT01qbWFja2xpbqFB
>>>
>>>
>>> MD+gAwIBEKE4BDYYADAQZLDW61U+**4aEZT4b+/X/**OpiQLHTQlyIUolm9EjVG4wXu+**
>>> 8Mn4lMYMZyR/F
>>>
>>>
>>> Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBV**EQlIuUk9DSEUuQ09Nam1hY2tsaW6hO**
>>> TA3oAMCARehMAQuEA
>>>
>>>
>>> CiWDGd28XkiaDAwpGyK0MqSawLCXs+**jKOFAA5BoSpayVTJJqjzAwSEitSu5z**
>>> BVoCAwHqADAgEAoRc
>>>
>>>
>>> EFURCUi5ST0NIRS5DT01qbWFja2xpb**qExMC+**gAwIBCKEoBCYIAKL5bzV4nQide/+6/**
>>> 2FE5LxYGULv
>>>
>>>
>>> 8Ws/Uu0RXrwAnR8/**ZuUh0TBVoCAwHqADAgEAoRcEFURCUi**
>>> 5ST0NIRS5DT01qbWFja2xpbqExMC+**gA
>>>
>>>
>>> wIBA6EoBCYIANgV0agxRmfBwY2Cb7g**Plm1oWDY5qhZidd8a0KmeIlBG56XLZ**
>>> jAzoTEwL6ADAgEBoS
>>>
>>>
>>> gEJggAo/**BQC7g4SWQY0UkU7rvoOAXwobVlAZn8**mesgQEznRDr2+**
>>> bxjME2gGDAWoAMCAQWhDwQNREJ
>>>
>>>
>>> SLlJPQ0hFLkNPTaExMC+**gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+**
>>> Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
>>>
>>>   R5aBPg==
>>> krbLastPwdChange: 20120809140419Z
>>> krbPasswordExpiration: 20130205140419Z
>>> userPassword::
>>> e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVV**F4VTdJLzh1TXREVnBWZjlnMWRxa0E9**PQ=
>>>   =
>>> krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSE**UuQ09NAA==
>>> krbLastSuccessfulAuth: 20121017184444Z
>>> krbLoginFailedCount: 0
>>> krbTicketFlags: 128
>>>
>>> So with all of that output, I would like to mention the discrepancy
>>> with ldap.conf.  Just trying to get any "sudo" working on RHEL 6.3 was
>>> problematic until I stumbled upon a post that mentioned
>>> creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or
>>> /etc/openldap/ldap.conf.  If I remove the /etc/sudo-ldap.conf then I
>>> have no sudo capabilities at all.
>>>
>>> -----Original Message-----
>>> From: Rich Megginson [mailto:rmegg...@redhat.com]
>>> Sent: Wednesday, October 17, 2012 2:06 PM
>>> To: Macklin, Jason {DASB~Branford}
>>> Cc: rcrit...@redhat.com; freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a
>>> per command or host level.
>>>
>>> On 10/17/2012 11:51 AM, Macklin, Jason wrote:
>>>
>>>> I assume that this iteration was with the correct credentials as it
>>>> responds with something other then "Invalid Credentials"
>>>>
>>>> ldapsearch -xLLL -H 
>>>> ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D 
>>>> "cn=directory
>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> No such object (32)
>>>>
>>>> Working account returns same thing...
>>>>
>>>> ldapsearch -xLLL -H 
>>>> ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D 
>>>> "cn=directory
>>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>>> Enter LDAP Password:
>>>> No such object (32)
>>>>
>>> Sorry, I though ipa would have configured your /etc/openldap/ldap.conf
>>> with your base dn.  Try this:
>>>
>>> ldapsearch -xLLL -H 
>>> ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D 
>>> "cn=directory
>>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*
>>>
>>>> -----Original Message-----
>>>> From: Rob Crittenden [mailto:rcrit...@redhat.com]
>>>> Sent: Wednesday, October 17, 2012 1:37 PM
>>>> To: Macklin, Jason {DASB~Branford}
>>>> Cc: rmegg...@redhat.com; freeipa-users@redhat.com
>>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a
>>>> per command or host level.
>>>>
>>>> Macklin, Jason wrote:
>>>>
>>>>> ldapsearch -xLLL -H 
>>>>> ldap://dbduvdu145.dbr.roche.**com<http://dbduvdu145.dbr.roche.com>-D 
>>>>> "cn=directory
>>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>>> Enter LDAP Password:
>>>>> ldap_bind: Invalid credentials (49)
>>>>>
>>>>> I know this user password because I reset it for the purpose of
>>>>> troubleshooting this issue with that account. I also get the same
>>>>> response when I use the admin account of my own account.
>>>>>
>>>> You use the password of the user you are binding as, in this case the
>>>> directory manager.
>>>>
>>>> rob
>>>>
>>>>  -----Original Message-----
>>>>> From: Rich Megginson [mailto:rmegg...@redhat.com]
>>>>> Sent: Wednesday, October 17, 2012 1:15 PM
>>>>> To: Macklin, Jason {DASB~Branford}
>>>>> Cc: s...@redhat.com; freeipa-users@redhat.com
>>>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on
>>>>> a per command or host level.
>>>>>
>>>>> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>>>>>
>>>>>> None of my users have an LDAP password being requested by running
>>>>>> that command (except the admin user).
>>>>>>
>>>>>> Does each user account require an ldap account to go along with
>>>>>> their login account?  I just get the following over and over no
>>>>>> matter which account I switch in the command...
>>>>>>
>>>>>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>>> manager" -W uid=admin \* krbPwdLockoutDuration ?
>>>>>> Enter LDAP Password:
>>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ?
>>>>>> Enter LDAP Password:
>>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory
>>>>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ?
>>>>>> Enter LDAP Password:
>>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>>>>>
>>>>> You have to specify which server to talk to using the -H
>>>>> ldap://fqdn.of.host option.
>>>>>
>>>>> ______________________________**_________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-users@redhat.com
>>>>> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users>
>>>>>
>>>>>
>>
> ______________________________**_________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users>
>
In case there is a bug I wanted to throw my hat in the ring because I am
having almost the same exact issue with my deployment of sudo.  I setup a
sudo rule on the ipa server with a single sudo command (/bin/su), for all
hosts, for a specific usergroup (netops). DIdn't work for my netops
user. When I eliminated the specific sudo command and went for all sudo
commands it started to work for my netops user.  So I decided to add a few
more hosts to test.  However now with the 2 additional host no sudo
commands work on either of these two hosts.

David
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to