[Freeipa-users] CentOS6.3 + Fedora17 + PackageKit / PolicyKit problem
Hi all, Just playing around with my setup that consists of two FreeIPA domain controllers on CentOS6.3 so the version of FreeIPA in use there is 2.2.0 So now after setting up my test laptop with Fedora 17 I proceeded to do an client installation and it seems freeipa-client version on F17 is also 2.2.0 but such things as sudo and sssd are much more recent than on CentOS. This caused few grey hairs until I got the sudo configuration to work by manipulating sssd.conf. Now that my user provisioned in FreeIPA domain can logon to my laptop, use sudo etc to install software I noticed a one little issue with policykit + packagekit combination. When through X I try to install an RPM package or do anything that requires admin rights it keeps asking for the root users password and not my sudo enabled FreeIPA users. If I have understood correctly packagekit advertises its request for admin rights through dbus to policykit which reads its policy files for matching description about the request. In this case the file seems to be: /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy In this policy file there is a lot of stuff which at this point makes no sense to me at all except that I guess that the lines: allow_activeauth_admin/allow_active describe that policykit should require user to enter an administrative level users password. Now on basic F17 installation where after first boot you create your first normal user account and give it an password there is an checkbox for Administrator or something similar which seems to add this user to be created in wheel and adm posix groups. When policykit requires an administrative users password it asks for this local users password if it is member of those groups (I guess) and if not it asks for the root users password. However when I add my FreeIPA user to the adm and wheel groups (silly since my sudo rules in FreeIPA give me already a full sudo rights) policykit does not seem to make a sense out of this situation and keep asking for the root users password. Now after all this bad english and a load of factual errors the actual question is: What needs to be configured and how to make FreeIPA provisioned user to be local administrator in policykits mind? If this is at all possible in current stage of development... p.s. I use an PackageKit here as an example target for the PolicyKit but I guess that anything to do with process rights elevation through PolicyKit is affected - not just the PackageKit application. -- Antti Peltonen | Homo sapiens | planet Earth email antti.pelto...@iki.fi irc BCOW @ IRCNet | Twitter @BrainCOW Ars longa, vita previs. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Resynchronize Samba Passwort
Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Marc. -- Marc Grimme E-Mail: grimme( at )atix.de ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Resynchronize Samba Passwort
On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CentOS6.3 + Fedora17 + PackageKit / PolicyKit problem
On Tue, 2012-10-16 at 09:53 +0300, Antti Peltonen wrote: Hi all, Just playing around with my setup that consists of two FreeIPA domain controllers on CentOS6.3 so the version of FreeIPA in use there is 2.2.0 So now after setting up my test laptop with Fedora 17 I proceeded to do an client installation and it seems freeipa-client version on F17 is also 2.2.0 but such things as sudo and sssd are much more recent than on CentOS. This caused few grey hairs until I got the sudo configuration to work by manipulating sssd.conf. Now that my user provisioned in FreeIPA domain can logon to my laptop, use sudo etc to install software I noticed a one little issue with policykit + packagekit combination. When through X I try to install an RPM package or do anything that requires admin rights it keeps asking for the root users password and not my sudo enabled FreeIPA users. If I have understood correctly packagekit advertises its request for admin rights through dbus to policykit which reads its policy files for matching description about the request. In this case the file seems to be: /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy In this policy file there is a lot of stuff which at this point makes no sense to me at all except that I guess that the lines: allow_activeauth_admin/allow_active describe that policykit should require user to enter an administrative level users password. Now on basic F17 installation where after first boot you create your first normal user account and give it an password there is an checkbox for Administrator or something similar which seems to add this user to be created in wheel and adm posix groups. When policykit requires an administrative users password it asks for this local users password if it is member of those groups (I guess) and if not it asks for the root users password. However when I add my FreeIPA user to the adm and wheel groups (silly since my sudo rules in FreeIPA give me already a full sudo rights) policykit does not seem to make a sense out of this situation and keep asking for the root users password. Have you logged out and logged back in after you have done these changes ? Changes to group membership do not take effect until the user logs out and logs back in. Now after all this bad english and a load of factual errors the actual question is: What needs to be configured and how to make FreeIPA provisioned user to be local administrator in policykits mind? If this is at all possible in current stage of development... It should make no difference where the user comes from, if it does it would be most likely a policykit bug/limitation/'feature' p.s. I use an PackageKit here as an example target for the PolicyKit but I guess that anything to do with process rights elevation through PolicyKit is affected - not just the PackageKit application. Understood, have you asked on policykit related mailing lists as well by chance ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
When I become the user in question I see the following in the sssd log. [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test] I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero). I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though. Thanks again! Jason From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/15/2012 04:46 PM, Dmitri Pal wrote: On 10/15/2012 04:34 PM, Macklin, Jason wrote: Hi, I apologize up front if this is obvious, but I'm having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get! What does sudo test return? Yes I meant HBAC. I might confused you and myself so let us start over. First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part. So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host? If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return. Thank you in advance for your assistance, Jason ___ Freeipa-users mailing list Freeipa-users@redhat.commailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.commailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On 10/16/2012 10:05 AM, Macklin, Jason wrote: When I become the user in question I see the following in the sssd log. [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test] I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero). Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server. I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though. Thanks again! Jason *From:*freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Dmitri Pal *Sent:* Monday, October 15, 2012 5:58 PM *To:* freeipa-users@redhat.com *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/15/2012 04:46 PM, Dmitri Pal wrote: On 10/15/2012 04:34 PM, Macklin, Jason wrote: Hi, I apologize up front if this is obvious, but I'm having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get! What does sudo test return? Yes I meant HBAC. I might confused you and myself so let us start over. First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part. So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host? If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return. Thank you in advance for your assistance, Jason ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Dmitri, I will give you everything I've got. If I can provide something else, let me know! Working User: Sudo debug output: [jmacklin@dbduwdu062 log]$ sudo -l sudo: ldap_set_option: debug - 0 sudo: ldap_set_option: tls_checkpeer - 1 sudo: ldap_set_option: tls_cacertfile - /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert - /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version - 3 sudo: ldap_set_option: timelimit - 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(52)=0x82 [sudo] password for jmacklin: Matching Defaults entries for jmacklin on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY, secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' sudo: ldap search 'sudoUser=+*' User jmacklin may run the following commands on this host: (root) ALL /var/log/secure output: Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; USER=root ; COMMAND=list Non-working user: Sudo debug output: [asteinfeld@dbduwdu062 ~]$ sudo -l sudo: ldap_set_option: debug - 0 sudo: ldap_set_option: tls_checkpeer - 1 sudo: ldap_set_option: tls_cacertfile - /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert - /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version - 3 sudo: ldap_set_option: timelimit - 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(52)=0x84 [sudo] password for asteinfeld: Sorry, user asteinfeld may not run sudo on dbduwdu062 /var/log/secure output: Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list Cheers. Jason From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, October 16, 2012 10:33 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/16/2012 10:05 AM, Macklin, Jason wrote: When I become the user in question I see the following in the sssd log. [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test] I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero). Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server. I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though. Thanks again! Jason From: freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users@redhat.commailto:freeipa-users@redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/15/2012 04:46 PM, Dmitri Pal wrote: On 10/15/2012 04:34 PM, Macklin, Jason wrote: Hi, I apologize up front if this is obvious, but I'm having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting,
Re: [Freeipa-users] Resynchronize Samba Passwort
On 10/16/2012 05:21 AM, Simo Sorce wrote: On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? What DNA configuration is used? -NGK ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Resynchronize Samba Passwort
On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: On 10/16/2012 05:21 AM, Simo Sorce wrote: On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? What DNA configuration is used? From a previous mail this look to be the config. Marc is this still correct ? Although my configurations looks ok, doesn't it? # ldapsearch -LLL -b cn=SambaSID,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config -D cn=Directory Manager -x -W Enter LDAP Password: dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject dnatype: sambaSID dnaprefix: S-1-5-21-1310149461-105972258- dnainterval: 1 dnamagicregen: assign dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) dnascope: dc=atix,dc=cl cn: SambaSid dnanextvalue: 15400 -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Macklin, Jason wrote: Yes, resolution works correctly at both the host and the freeIPA server. Dmitri, I am still quite new to LDAP so I'm not sure exactly what I should be looking for when running ldapsearch. The attempts that I have made have been less then fruitful though... examples follow /usr/bin/ldapsearch -I -H ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=comSASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: This sort of return occurs for either working or non-working users both! As I am new to ldap... is there a specific ldapsearch command/option I should be using? You want to be authenticated to search the sudo data, so do something like: $ kinit admin (or some user) $ ldapsearch -Y GSSAPI ... rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Resynchronize Samba Passwort
On 10/16/2012 02:40 PM, Simo Sorce wrote: On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: On 10/16/2012 05:21 AM, Simo Sorce wrote: On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign I think that this needs to be --setattr=assign. The prefix should not be included when specifying the magic value to trigger generation. --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? What DNA configuration is used? From a previous mail this look to be the config. Marc is this still correct ? Although my configurations looks ok, doesn't it? # ldapsearch -LLL -b cn=SambaSID,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config -D cn=Directory Manager -x -W Enter LDAP Password: dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject dnatype: sambaSID dnaprefix: S-1-5-21-1310149461-105972258- dnainterval: 1 dnamagicregen: assign dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) dnascope: dc=atix,dc=cl cn: SambaSid dnanextvalue: 15400 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Setting up sudo in FreeIPA v2.2
Can you turn on debugging? sudoers_debug2 to /etc/sudo-ldap.conf (assumes RHEL6.3) Also you could try adding the host directly to the sudo rule and not via a host group as that seems buggy regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Toasted Penguin [toastedpenguini...@gmail.com] Sent: Wednesday, 17 October 2012 10:24 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 I have the server setup to manage sudo and I configured a target client to use the IPA server for sudo. When a user tries to use sudo (in this case sudo su -) it fails and they get the error user is not allowed to run sudo on client-host. This incident will be reported. I verified via the log files that the client is making requests to the IPA server when the user is attemping to use sudo and it fails. I temporarily disabled using the IPA server for sudo and I get the standard User not in the sudoers file Its starting to look like the server rules maybe the issue but I believe I have the sudo rule setup correctly. I created a sudo command /bin/su, created a sudo rule Sudo to root , added the group the user in question is a part of to the WHO--User Groups; Added the Host Group the target client host is part of to Access This Host--Host Groups and added the sudo command to the sudo rule via Allow--Sudo Allow Commands. When I delete the sudo rule I get the same result as I did when I temporarily disbled the client host using tghe IPA server for sudo verification. Any ideas why or where to look to figure out this issue? Thanks, David ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Resynchronize Samba Passwort
On Tue, 2012-10-16 at 14:51 -0700, Nathan Kinder wrote: On 10/16/2012 02:40 PM, Simo Sorce wrote: On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: On 10/16/2012 05:21 AM, Simo Sorce wrote: On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign I think that this needs to be --setattr=assign. The prefix should not be included when specifying the magic value to trigger generation. Nathan, you were not included in the previous mails, but options have been tried and they seem to fail the same way (ie the actual passed in value is stored instead of generating a new value). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Setting up sudo in FreeIPA v2.2
Toasted Penguin wrote: I have the server setup to manage sudo and I configured a target client to use the IPA server for sudo. When a user tries to use sudo (in this case sudo su -) it fails and they get the error user is not allowed to run sudo on client-host. This incident will be reported. I verified via the log files that the client is making requests to the IPA server when the user is attemping to use sudo and it fails. I temporarily disabled using the IPA server for sudo and I get the standard User not in the sudoers file Its starting to look like the server rules maybe the issue but I believe I have the sudo rule setup correctly. I created a sudo command /bin/su, created a sudo rule Sudo to root , added the group the user in question is a part of to the WHO--User Groups; Added the Host Group the target client host is part of to Access This Host--Host Groups and added the sudo command to the sudo rule via Allow--Sudo Allow Commands. When I delete the sudo rule I get the same result as I did when I temporarily disbled the client host using tghe IPA server for sudo verification. Any ideas why or where to look to figure out this issue? Thanks, David I took a look at the docs and they state to edit /etc/nscld.conf. You want /etc/ldap.conf for the configuration. Can you give that a try? Adding sudoers_debug 2 should provide copious information on stdout. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] web admin tool will not login with kerberos ticket
I had a happy, working 2.2 FreeIPA installation humming along last week. I had
to do some maintenance so I shut everything down. When I brought everything up,
I can no longer log into the web admin tool. I get a Kerberos ticket is no
longer valid error.
Using the troubleshooting pages on the wiki as a guide, I can kinit
successfully and see the tickets using klist. I can use the ldapsearch tool
using GSSAPI to authenticate as well and can return results from the ldap
server. 'ldapsearch -Y GSSAPI -b dc=dcc,dc=mobi uid=admin' returns a valid
ldap recors for my admin user. I ran this command kinit from multiple kerberos
principals/users and each worked.
I verified my config settings again with firefox and they are still set
correctly (auth.delegation-uris, auth.trusted-users both set to my domain
.dcc.mobi). The cert was accepted (no warnings about the cert not being trusted
because I had already set it to trusted). I turned on the NSPR logging as
described in the documents, and didn't see an error, although I can't tell if
this is correct:
492291904[7f4d1d31f6a0]: using REQ_DELEGATE
492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi
492291904[7f4d1d31f6a0]: using negotiate-gss
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI()
492291904[7f4d1d31f6a0]: Attempting to load gss functions
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init()
492291904[7f4d1d31f6a0]: nsHttpNegotiateAuth::GenerateCredentials()
[challenge=Negotiate]
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken()
492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0]
492291904[7f4d1d31f6a0]: Sending a token of length 1394
There is nothing in /var/log/httpd/error_log. /var/log/httpd/access_log does
have a few entries:
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ca/ocsp HTTP/1.1 200 2298
- Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ipa/session/json HTTP/1.1
401 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] GET /ipa/session/login_kerberos
HTTP/1.1 401 1861
10.1.1.10 - ad...@dcc.mobi [16/Oct/2012:18:05:26 -0500] GET
/ipa/session/login_kerberos HTTP/1.1 200 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ipa/session/json HTTP/1.1
401 -
The 401's aren't surprising here since somehow, something is not properly
authenticating.
I also looked in /var/log/krb5kdc.log and see the following line when
authenticating:
Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1 etypes {18})
10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18 tkt=18 ses=18},
ad...@dcc.mobi for krbtgt/dcc.m...@dcc.mobi
I don't believe this describes an error, but I'm not an expert reading that log
type.
From what I can tell, the problems seem to be between the apache server and the
browser. Both worked fine together last week. Is there something I can turn on
in Apache (perhaps in the ipa.conf or auth_kerb.conf files) that can help debug
this? Or better yet, anyone else seen this and have an answer? Is there some
key/ticket/etc associated with the http server that might be wrong now
(somehow whacked during the reboot)?
Thanks,
Brian
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA v cron
Hi, I have local users that can use cron, but IPA'd users cannot I get a permission denied via pam, but since a localuser can crontab -e that seems to make no sense. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] web admin tool will not login with kerberos ticket
On 10/16/2012 07:30 PM, Brian Vetter wrote:
I had a happy, working 2.2 FreeIPA installation humming along last
week. I had to do some maintenance so I shut everything down. When I
brought everything up, I can no longer log into the web admin tool. I
get a Kerberos ticket is no longer valid error.
Using the troubleshooting pages on the wiki as a guide, I can kinit
successfully and see the tickets using klist. I can use the ldapsearch
tool using GSSAPI to authenticate as well and can return results from
the ldap server. 'ldapsearch -Y GSSAPI -b dc=dcc,dc=mobi uid=admin'
returns a valid ldap recors for my admin user. I ran this command
kinit from multiple kerberos principals/users and each worked.
I verified my config settings again with firefox and they are still
set correctly (auth.delegation-uris, auth.trusted-users both set to my
domain .dcc.mobi). The cert was accepted (no warnings about the cert
not being trusted because I had already set it to trusted). I turned
on the NSPR logging as described in the documents, and didn't see an
error, although I can't tell if this is correct:
492291904[7f4d1d31f6a0]: using REQ_DELEGATE
492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi
492291904[7f4d1d31f6a0]: using negotiate-gss
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI()
492291904[7f4d1d31f6a0]: Attempting to load gss functions
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init()
492291904[7f4d1d31f6a0]:
nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken()
492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0]
492291904[7f4d1d31f6a0]: Sending a token of length 1394
There is nothing in /var/log/httpd/error_log.
/var/log/httpd/access_log does have a few entries:
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ca/ocsp
HTTP/1.1 200 2298 - Mozilla/5.0 (X11; Linux x86_64; rv:16.0)
Gecko/20100101 Firefox/16.0
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ipa/session/json
HTTP/1.1 401 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] GET
/ipa/session/login_kerberos HTTP/1.1 401 1861
10.1.1.10 - ad...@dcc.mobi mailto:ad...@dcc.mobi
[16/Oct/2012:18:05:26 -0500] GET /ipa/session/login_kerberos
HTTP/1.1 200 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ipa/session/json
HTTP/1.1 401 -
The 401's aren't surprising here since somehow, something is not
properly authenticating.
I also looked in /var/log/krb5kdc.log and see the following line when
authenticating:
Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1
etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18
tkt=18 ses=18}, ad...@dcc.mobi mailto:ad...@dcc.mobi for
krbtgt/dcc.m...@dcc.mobi mailto:krbtgt/dcc.m...@dcc.mobi
I don't believe this describes an error, but I'm not an expert reading
that log type.
From what I can tell, the problems seem to be between the apache
server and the browser. Both worked fine together last week. Is there
something I can turn on in Apache (perhaps in the ipa.conf or
auth_kerb.conf files) that can help debug this? Or better yet, anyone
else seen this and have an answer? Is there some key/ticket/etc
associated with the http server that might be wrong now (somehow
whacked during the reboot)?
Just to reiterate.
1) You have a server that got rebooted.
2) After reboot kinit admin works
3) klist shows tickets
4) logs show no errors
5) You can do ldap search - no problem
6) You stop FF and start it and it says Kerberos ticket is no longer valid
This is very similar to thread started by David Sastre with title
Problem with webui: kerberos ticket no longer valid.
The start of the thread is in August and the end is in September archive.
It might have an answer for you.
HTH
Thanks,
Brian
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA v cron
On 10/16/2012 07:23 PM, Steven Jones wrote: Hi, I have local users that can use cron, but IPA'd users cannot I get a permission denied via pam, but since a localuser can crontab -e that seems to make no sense. They get denied when they do what? At what moment they get access denied? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA v cron
Hi, Created and added crond to the HBAC rule, now fine. Thanks regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Wednesday, 17 October 2012 12:48 p.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA v cron On 10/16/2012 07:23 PM, Steven Jones wrote: Hi, I have local users that can use cron, but IPA'd users cannot I get a permission denied via pam, but since a localuser can crontab -e that seems to make no sense. They get denied when they do what? At what moment they get access denied? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Setting up sudo in FreeIPA v2.2
On the host in question Run the command: domainname That wants to match whatever your domain is. If it doesn't it will fail even if you have all the server rules configured correctly. This is a sudo + netgroups/hostgroups 'feature' ~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aqu...@citrixonline.com http://www.citrixonline.com On Oct 16, 2012, at 2:26 PM, Toasted Penguin toastedpenguini...@gmail.com wrote: I have the server setup to manage sudo and I configured a target client to use the IPA server for sudo. When a user tries to use sudo (in this case sudo su -) it fails and they get the error user is not allowed to run sudo on client-host. This incident will be reported. I verified via the log files that the client is making requests to the IPA server when the user is attemping to use sudo and it fails. I temporarily disabled using the IPA server for sudo and I get the standard User not in the sudoers file Its starting to look like the server rules maybe the issue but I believe I have the sudo rule setup correctly. I created a sudo command /bin/su, created a sudo rule Sudo to root , added the group the user in question is a part of to the WHO--User Groups; Added the Host Group the target client host is part of to Access This Host--Host Groups and added the sudo command to the sudo rule via Allow--Sudo Allow Commands. When I delete the sudo rule I get the same result as I did when I temporarily disbled the client host using tghe IPA server for sudo verification. Any ideas why or where to look to figure out this issue? Thanks, David ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
