[Freeipa-users] ipa: ERROR: attribute idnsAllowTransfer not allowed
Hi, I am trying to add a new DNS zone to our IPA server, but I receive the following error: $ ipa dnszone-add example.com --name-server=ns01.example.com --admin-email=hostmaster.example.com ipa: ERROR: attribute idnsAllowTransfer not allowed I get the same error no matter if I attempt to add a forward or a reverse zone. I am using IPA 2.2 on RHEL 6.3: bind-9.8.2-0.10.rc1.el6_3.3.x86_64 bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.x86_64 bind-libs-9.8.2-0.10.rc1.el6_3.3.x86_64 bind-utils-9.8.2-0.10.rc1.el6_3.3.x86_64 ipa-admintools-2.2.0-16.el6.x86_64 ipa-client-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-python-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 krb5-libs-1.9-33.el6_3.3.x86_64 krb5-pkinit-openssl-1.9-33.el6_3.3.x86_64 krb5-server-1.9-33.el6_3.3.x86_64 krb5-server-ldap-1.9-33.el6_3.3.x86_64 krb5-workstation-1.9-33.el6_3.3.x86_64 selinux-policy-3.7.19-155.el6_3.4.noarch selinux-policy-targeted-3.7.19-155.el6_3.4.noarch slapi-nis-0.40-1.el6.x86_64 We do have several dns zones in IPA today, so this has worked earlier. Is this a known error? Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server
On Sat, Feb 23, 2013 at 10:40:03PM +, Dale Macartney wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2013 10:36 PM, Rob Crittenden wrote: Dale Macartney wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Even folks I've verified this both in a kickstart and via manual install to verify any user error on my part. I have a clean installation of RHEL 6.4 for an IPA domain of example.com I also have several clients which are also clean installs of rhel 6.4 and although I can see ipa users via getent and even acquire a tgt's successfully, I am unable to login with any ipa user on any ipa member server. I see the same results for any type of login attempt, e.g. gnome desktop or ssh My client installation is done by this command. ipa-client-install -U -p admin -w redhat123 --mkhomedir --enable-dns-updates IPA client version 3.0.0-25 SSSD version 1.9.2-82 Logs from client as as follows. == /var/log/secure == Feb 23 22:10:07 workstation02 sshd[2419]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.1.254 user=admin Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): User info message: Your password will expire in 89 day(s). FTR, this is a known bug that will be fixed in an asynchronous errata Very Soon Now. Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.1.254 user=admin == /var/log/btmp == s ssh:nottyadmin10.0.1.254@)Q ? == /var/log/secure == Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:account): Access denied for user admin: 4 (System error) What state is your SELinux in? Permissive/Enforcing/Disabled ? Feb 23 22:10:08 workstation02 sshd[2419]: Failed password for admin from 10.0.1.254 port 4 ssh2 Feb 23 22:10:08 workstation02 sshd[2421]: fatal: Access denied for user admin by PAM account configuration == /var/log/Xorg.0.log == [ 604.308] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 connected from local host ( uid=42 gid=42 pid=1958 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 284 [ 604.312] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 disconnected == /var/log/messages == Feb 23 22:12:45 workstation02 ntpd[2359]: synchronized to LOCAL(0), stratum 5 Feb 23 22:13:48 workstation02 ntpd[2359]: synchronized to 10.0.1.12, stratum 11 interactive shell output as follows [mac@rhodey ~]$ ssh admin@10.0.1.102 admin@10.0.1.102's password: Your password will expire in 89 day(s). Connection closed by 10.0.1.102 [mac@rhodey ~]$ Am I doing something rather trivially wrong or is there something fishy going on here? Thanks in advance. I'd check your HBAC configuration. rob That is actually the very first thing I did. As it is a 100% clean installation of IPA, plus the addition of one user and one IPA replica. all users are granted access to all hosts. [root@ds01 ~]# ipa hbacrule-find - --- 1 HBAC rule matched - --- Rule name: allow_all User category: all Host category: all Source host category: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE - Number of entries returned 1 - [root@ds01 ~]# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRKUVAAAoJEAJsWS61tB+qmMwQAJgO3zJsbQkKqhgdj6qjfvbH EJHQOCEA55Mf2FgY4cUjeOj2oulny3HLxFQJql6OGYOk73zx48JR0VZdalyXp4Jc bUKkog+5jnamcEpm5qcRfvpLrITayamqMTgPzvOdrCWnVYSNTxjA07y7Sh/ZOpK5 XSsYTaMBKFLsE20CAE/a/PPJpL/43fP59+nK0yGgClwA5V3FIMBLZo7WKOGFsVJK lK+Couo3FPwiThp3klHudokQ4w24MdDc9aNKz4ZatcnqHK9nXeBNIya8FdYAtMqT Us6Lzkq0YOk7IKFU5qgqUtkXuCmRfRLZDZYngpug4S97S0wmG7eo191VPliKsCOO CuWDaSDtUMbD5li7yzUEnhwUOI+9tLSD98rTO7oqGADQQqvmgz78/A9uQAVfRSIS 7PpmqUsl2pdC1XZ7Vy0K6vrqc7ojQkwwlFVmvY+TMBs2ukKrDz38bnRzfevxpZNe pm77dn8iF2NGqGpPqbrRvXwenIqi35j/6adBhGtDkAkdSKFXyZbDXRms+ro3oxXI StrYPHy4td02Fe4MyFrc3s7uIJvYuZGB+ULRKDAptnZetKhaP58VoapQJYrKrxdd N5hqf4EMwQ9b++Y5Bf9fzlA4osIDgf3uS+8/orL0KuXBq0vGYMqyTDE9leRMqamh ruH0DYhFtmabbPzxv7uA =sdSi -END PGP SIGNATURE- ___ 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] RHEL 6.4 ipa-client install on ipa member server
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/25/2013 10:15 AM, Jakub Hrozek wrote:
On Sat, Feb 23, 2013 at 10:40:03PM +, Dale Macartney wrote:
On 02/23/2013 10:36 PM, Rob Crittenden wrote:
Dale Macartney wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Even folks
I've verified this both in a kickstart and via manual install to
verify
any user error on my part.
I have a clean installation of RHEL 6.4 for an IPA domain of
example.com
I also have several clients which are also clean installs of rhel 6.4
and although I can see ipa users via getent and even acquire a tgt's
successfully, I am unable to login with any ipa user on any ipa
member
server.
I see the same results for any type of login attempt, e.g. gnome
desktop
or ssh
My client installation is done by this command.
ipa-client-install -U -p admin -w redhat123 --mkhomedir
--enable-dns-updates
IPA client version 3.0.0-25
SSSD version 1.9.2-82
Logs from client as as follows.
== /var/log/secure ==
Feb 23 22:10:07 workstation02 sshd[2419]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.0.1.254 user=admin
Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth):
User info
message: Your password will expire in 89 day(s).
FTR, this is a known bug that will be fixed in an asynchronous errata
Very Soon Now.
Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth):
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.0.1.254 user=admin
== /var/log/btmp ==
s ssh:nottyadmin10.0.1.254@)Q
?
== /var/log/secure ==
Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:account):
Access
denied for user admin: 4 (System error)
What state is your SELinux in? Permissive/Enforcing/Disabled ?
Another fail on my part. Works fine in permissive mode.
AVC denials listed below..
type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for
pid=2271 comm=sshd path=/var/lib/sss/mc/passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for
pid=2275 comm=krb5_child path=/etc/selinux/config dev=dm-0
ino=392854 scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=logins dev=dm-0 ino=392943
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for
pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for
pid=1380 comm=sssd_pam name=admin dev=dm-0 ino=392951
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
Feb 23 22:10:08 workstation02 sshd[2419]: Failed password for
admin from
10.0.1.254 port 4 ssh2
Feb 23 22:10:08
Re: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server
On Mon, Feb 25, 2013 at 10:30:44AM +, Dale Macartney wrote:
What state is your SELinux in? Permissive/Enforcing/Disabled ?
Another fail on my part. Works fine in permissive mode.
No, the SSSD should be working out of the box with SELinux Enforcing.
AVC denials listed below..
type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for
pid=2271 comm=sshd path=/var/lib/sss/mc/passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
^ This is SElinux denying access to the fast in-memory cache.
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for
pid=2275 comm=krb5_child path=/etc/selinux/config dev=dm-0
ino=392854 scontext=system_u:system_r:sssd_t:s0
Interesting, I'm not aware of any code in the krb5 child process that
would do anything selinux-related. I wonder if libkrb5 might be the
culprit..rpm says it *is* linked against libselinux as well.
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=logins dev=dm-0 ino=392943
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for
pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for
pid=1380 comm=sssd_pam name=admin dev=dm-0 ino=392951
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
This is SSSD trying to write the user login mapping.
What version is your selinux-policy?
Was your system properly labeled?
Does restorecon -Rvv /etc/selinux help?
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/25/2013 10:58 AM, Jakub Hrozek wrote:
On Mon, Feb 25, 2013 at 10:30:44AM +, Dale Macartney wrote:
What state is your SELinux in? Permissive/Enforcing/Disabled ?
Another fail on my part. Works fine in permissive mode.
No, the SSSD should be working out of the box with SELinux Enforcing.
AVC denials listed below..
type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for
pid=2271 comm=sshd path=/var/lib/sss/mc/passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
^ This is SElinux denying access to the fast in-memory cache.
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for
pid=2275 comm=krb5_child path=/etc/selinux/config dev=dm-0
ino=392854 scontext=system_u:system_r:sssd_t:s0
Interesting, I'm not aware of any code in the krb5 child process that
would do anything selinux-related. I wonder if libkrb5 might be the
culprit..rpm says it *is* linked against libselinux as well.
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=logins dev=dm-0 ino=392943
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for
pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for
pid=1380 comm=sssd_pam name=admin dev=dm-0 ino=392951
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
This is SSSD trying to write the user login mapping.
What version is your selinux-policy?
Was your system properly labeled?
Does restorecon -Rvv /etc/selinux help?
Interesting, after using restorecon, yes it now allows a successful
login. I am curious how the contexts would have become incorrectly set
as the machine was provisioned with a rather trivial kickstart.
output of restorecon is below.
[root@workstation01 ~]# restorecon -Rvv /etc/selinux/
restorecon reset /etc/selinux/targeted/logins context
system_u:object_r:selinux_config_t:s0-system_u:object_r:selinux_login_config_t:s0
restorecon reset /etc/selinux/targeted/logins/admin context
system_u:object_r:selinux_config_t:s0-system_u:object_r:selinux_login_config_t:s0
[root@workstation01 ~]#
selinux policy version 3.7.19-195.el6_4.1
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRK0WgAAoJEAJsWS61tB+qnnYQAJJgXcVUUU2DdOUFR34GeU97
NgAoJfbPdL8wtXWT+qqnwdGWRRFO4fgfZF6DBh21suW0f4PrNiv8PPmq/jSXqbF6
K+PwT/txjU4nvm+9j2uvJGvgysisVXwVXkUHGlyljG9FyrilaLi0rnk2cuZ0LdC2
Zwt0x9u1f+yXU4l4IGWJNxW26C+wr5oAZvpCbzGO19ODCctBFvGTox0yFVCE1tB2
Re: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server
On Mon, Feb 25, 2013 at 11:06:09AM +, Dale Macartney wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/25/2013 10:58 AM, Jakub Hrozek wrote:
On Mon, Feb 25, 2013 at 10:30:44AM +, Dale Macartney wrote:
What state is your SELinux in? Permissive/Enforcing/Disabled ?
Another fail on my part. Works fine in permissive mode.
No, the SSSD should be working out of the box with SELinux Enforcing.
AVC denials listed below..
type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for
pid=2271 comm=sshd path=/var/lib/sss/mc/passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
^ This is SElinux denying access to the fast in-memory cache.
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for
pid=2275 comm=krb5_child path=/etc/selinux/config dev=dm-0
ino=392854 scontext=system_u:system_r:sssd_t:s0
Interesting, I'm not aware of any code in the krb5 child process that
would do anything selinux-related. I wonder if libkrb5 might be the
culprit..rpm says it *is* linked against libselinux as well.
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=logins dev=dm-0 ino=392943
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for
pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for
pid=1380 comm=sssd_pam name=admin dev=dm-0 ino=392951
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
This is SSSD trying to write the user login mapping.
What version is your selinux-policy?
Was your system properly labeled?
Does restorecon -Rvv /etc/selinux help?
Interesting, after using restorecon, yes it now allows a successful
login. I am curious how the contexts would have become incorrectly set
as the machine was provisioned with a rather trivial kickstart.
output of restorecon is below.
[root@workstation01 ~]# restorecon -Rvv /etc/selinux/
restorecon reset /etc/selinux/targeted/logins context
system_u:object_r:selinux_config_t:s0-system_u:object_r:selinux_login_config_t:s0
restorecon reset /etc/selinux/targeted/logins/admin context
system_u:object_r:selinux_config_t:s0-system_u:object_r:selinux_login_config_t:s0
[root@workstation01 ~]#
selinux policy version 3.7.19-195.el6_4.1
I'm not sure, was the system installed with that version or upgraded to
it?
I would also suggest to restorecon /var/lib/sss/mc/passwd to get rid of
the memory cache denials. That should also allow faster initgroups (and
by extension logins) operation.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/25/2013 11:15 AM, Jakub Hrozek wrote:
On Mon, Feb 25, 2013 at 11:06:09AM +, Dale Macartney wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/25/2013 10:58 AM, Jakub Hrozek wrote:
On Mon, Feb 25, 2013 at 10:30:44AM +, Dale Macartney wrote:
What state is your SELinux in? Permissive/Enforcing/Disabled ?
Another fail on my part. Works fine in permissive mode.
No, the SSSD should be working out of the box with SELinux Enforcing.
AVC denials listed below..
type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for
pid=2271 comm=sshd name=passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for
pid=2271 comm=sshd path=/var/lib/sss/mc/passwd dev=dm-0 ino=914246
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
^ This is SElinux denying access to the fast in-memory cache.
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for
pid=2275 comm=krb5_child name=config dev=dm-0 ino=392854
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for
pid=2275 comm=krb5_child path=/etc/selinux/config dev=dm-0
ino=392854 scontext=system_u:system_r:sssd_t:s0
Interesting, I'm not aware of any code in the krb5 child process that
would do anything selinux-related. I wonder if libkrb5 might be the
culprit..rpm says it *is* linked against libselinux as well.
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=logins dev=dm-0 ino=392943
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for
pid=1380 comm=sssd_pam name=adminoTfIUQ
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name }
for pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for
pid=1380 comm=sssd_pam name=adminoTfIUQ dev=dm-0 ino=393233
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for
pid=1380 comm=sssd_pam name=admin dev=dm-0 ino=392951
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:selinux_config_t:s0 tclass=file
This is SSSD trying to write the user login mapping.
What version is your selinux-policy?
Was your system properly labeled?
Does restorecon -Rvv /etc/selinux help?
Interesting, after using restorecon, yes it now allows a successful
login. I am curious how the contexts would have become incorrectly set
as the machine was provisioned with a rather trivial kickstart.
output of restorecon is below.
[root@workstation01 ~]# restorecon -Rvv /etc/selinux/
restorecon reset /etc/selinux/targeted/logins context
system_u:object_r:selinux_config_t:s0-system_u:object_r:selinux_login_config_t:s0
restorecon reset /etc/selinux/targeted/logins/admin context
system_u:object_r:selinux_config_t:s0-system_u:object_r:selinux_login_config_t:s0
[root@workstation01 ~]#
selinux policy version 3.7.19-195.el6_4.1
I'm not sure, was the system installed with that version or upgraded to
it?
All repositories are available during install, so no need for upgrade
post install. IPA client install runs as part of %post.
I would also suggest to restorecon /var/lib/sss/mc/passwd to get rid of
the memory cache denials. That should also allow faster initgroups (and
by extension logins) operation.
Good to know, presumably this will be
Re: [Freeipa-users] ipa: ERROR: attribute idnsAllowTransfer not allowed
Hi, On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote: $ ipa dnszone-add example.com --name-server=ns01.example.com --admin-email=hostmaster.example.com ipa: ERROR: attribute idnsAllowTransfer not allowed [..] Is this a known error? Yes, the idnsZone objectClass entry was not updated properly during ipa-server update process. To fix this the schema has to be modified, https://access.redhat.com/knowledge/solutions/301213 has the details. cheers, Christian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Transferring mastership to a new server
On 02/25/2013 03:04 PM, Bret Wortman wrote: So I managed to replicate my old IPA master onto a new server, and now I'd like that server to be the center of the universe. The master from which all (new) replicas are created. At present, there are no other replicas, just this one server now that the original has been decommissioned. I did discover that I can't create replicas from it because it knows it was cloned from another. What do I need to do to it so that it can take over as the new master? Install the CA on it (ipa-ca-install). If you have DNS set up, you'll want to run ipa-dns-install as well. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed
On Mon, February 25, 2013 12:59, Christian Horn wrote: Hi, On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote: $ ipa dnszone-add example.com --name-server=ns01.example.com --admin-email=hostmaster.example.com ipa: ERROR: attribute idnsAllowTransfer not allowed [..] Is this a known error? Yes, the idnsZone objectClass entry was not updated properly during ipa-server update process. To fix this the schema has to be modified, https://access.redhat.com/knowledge/solutions/301213 has the details. Thank you. That worked just fine. :) Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Non-Prod instance
Hello! Does anyone out there run two instances of freeipa, prod non-prod instances? Are there any issues to be wary of in this scenario? Any gotchas? Do you use the same realms domain names between instances? Perhaps the fellow who upgraded his prod server to 6.4 might appreciate this . . . Thanks a lot, Guy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] nsslapd-changelogmaxage
Hi, I have multimaster replication enviroment, IPA v2.2 on Fedora 17. On each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big size (~7GB). This is half of all available space for '/'. I found that changelog file can be trim using 'nsslapd-changelogmaxage' parameter. By default, this parameter is not set in dse.ldif (is this correct?). My questions are: a) where should I put 'nsslapd-changelogmaxage' parameter, into tree: cn=Retro Changelog Plugin, cn=config or cn=changelog5,cn=config. b) what are the consequences when I set this parameter to nsslapd-changelogmaxage: 10d? c) Is any other possibility to limit increase of this file? Kriss ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] nsslapd-changelogmaxage
On 02/25/2013 11:33 AM, Kriss Von Prosst wrote: Hi, I have multimaster replication enviroment, IPA v2.2 on Fedora 17. On each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big size (~7GB). This is half of all available space for '/'. I found that changelog file can be trim using 'nsslapd-changelogmaxage' parameter. By default, this parameter is not set in dse.ldif (is this correct?). My questions are: a) where should I put 'nsslapd-changelogmaxage' parameter, into tree: cn=Retro Changelog Plugin, cn=config or cn=changelog5,cn=config. Not Retro Changelog https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd b) what are the consequences when I set this parameter to nsslapd-changelogmaxage: 10d? c) Is any other possibility to limit increase of this file? There is also the nsslapd-changelogmaxentries parameter https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5 Kriss ___ 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] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
On Mon, 2013-02-25 at 18:48 +, Mercer, Rodney wrote: On Thu, 2013-02-21 at 03:53 -0500, Dmitri Pal wrote: On 02/20/2013 08:44 AM, Rodney L. Mercer wrote: On Tue, 2013-02-19 at 21:05 -0500, Dmitri Pal wrote: On 02/19/2013 09:14 AM, Rodney L. Mercer wrote: On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote: On 02/16/2013 12:14 PM, Mercer, Rodney wrote: From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Sigbjorn Lie [sigbj...@nixtra.com] Sent: Saturday, February 16, 2013 6:29 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC On 02/15/2013 10:31 PM, Dmitri Pal wrote: On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: I agree with schema support being enough for now. I do not expect the ipa mgmt tools to support Solaris rbac mgmt. The ipa mgmt tools are great, but I already have other data in the ipa ldap that I have to manage manually anyway. Rgds, Siggi Rob Crittenden rcrit...@redhat.com wrote: Dag Wieers wrote: On Thu, 14 Feb 2013, Rob Crittenden wrote: Sigbjorn Lie wrote: On 02/13/2013 04:10 PM, Rob Crittenden wrote: Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solar is ? (We noticed that RBAC mentioned in the IPA web interface only relates toIPA management). No, IPA doesn't support RBAC on Solaris. I've come across the same issue. This is just a matter of extending the schema. Would there be any interest for adding the Solaris RBAC schema as a part of the standard IPA distributed LDAP schema? Consider the following: What else would have to be put in to support this? Once the schema is established, can SSSD be extended to use this and potentially be referenced in nsswitch.conf as it is implemented on Solaris? IE: tail -5 /etc/nsswitch.conf user_attr: sssd auth_attr: sssd prof_attr: sssd exec_attr: sssd project:sssd Before we define how it is passed/exposed it would nice to understand who on Linux will be consuming it out of SSSD? I don't think Linux would consume these attributes. They are specific to the Role Based Access Control solution implemented in Solaris. Rgds, Siggi -- Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so? I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL. We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application. Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients. If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL. I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation. We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application. Since IdM and SSD already support a) HBAC b) SUDO c) SELinux user mapping I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access
