[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Jakub Hrozek via FreeIPA-users]

> On 4 Aug 2017, at 23:08, Alexandre Pitre via FreeIPA-users 
>  wrote:
> 
> Turns out, I'm still getting the same problem. It works right away after I 
> force clean the sssd cache: systemctl stop sssd ; rm -f /var/lib/sss/db/* 
> /var/log/sssd/* ; systemctl start sssd
> 
> After some time, trying to log back on the same system I see the login prompt 
> is much quicker when I type adu...@ad.com 
> Instead of getting a simple "Password:" prompt  I get adu...@ad.com 
> @centos.domain.ad.com 's 
> password.
> 
> If I login as root and stop/start and clean the sssd cache, it start working 
> again.
> 

Are you sure cleaning the cache is needed? Because I think your issue is 
different. The fact that you get a faster login prompt and the “Server not 
found…” message both point to the sssd going offline.

You could run ‘sssctl domain-status’ to show if the domain is online or offline 
(requires the ‘ifp’ service to be enabled until RHEL-7.4/upstream 1.15.x) or 
look into the logs for messages like “Going offline”.

> /var/log/messages is filled with:
> 
> centos sssd_be: GSSAPI Error: Unspecified GSS failure.  Minor code may 
> provide more information (Server krbtgt/ad@ipa.ad.com 
>  not found in Kerberos database)

This is the trust principal. Are you sure all your replicas are either trust 
agents or you ran “ipa-adtrust-install” on them?

> 
> 
> Any thoughts ?
> 
> Thanks,
> Alex
> 
> 
> On Tue, Aug 1, 2017 at 2:58 AM, Jakub Hrozek  > wrote:
> On Mon, Jul 31, 2017 at 05:47:11PM -0400, Alexandre Pitre wrote:
> > Bull-eye Jakub, that did the trick. I should have posted for help on the
> > mailing list sooner. Thanks you so much, you are saving my ass.
> >
> > It makes sense to increase the krb5_auth_timeout as my AD domain
> > controllers servers are worldwide. Currently they exist in 3 regions: North
> > America, Europe and Asia.
> >
> > The weird thing is it seems that when a linux host try to authenticate
> > against my AD, it just randomly select an AD DC from the _kerberos  SRV
> > records. Normally, on the windows side, if "sites and services" are setup
> > correctly with subnet defined and binded to sites, a windows client
> > shouldn't try to authenticate against an AD DC that isn't local to his
> > site. This mechanism doesn't  seem to apply to my linux hosts. Is it
> > because it's only available for windows hosts ? Is there another way to
> > force linux clients to authenticate against AD DC local to their site ?
> 
> We haven't implemented the site selection for the clients yet, only for
> servers, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1416528 
> 
> 
> >
> > For now, I set the krb5_auth_timeout to 120 seconds. I had to completely
> > stop sssd and start it again. A colleague mentioned that sssd has a known
> > issue with restart apparently.
> 
> I'm not aware of any such issue..
> 
> >
> > Also, I'm curious about ports requirements. Going from linux hosts to AD, I
> > only authorize 88 TCP/UDP. I believe that's all I need.
> 
> Yes, from the clients, that should be enough. The servers need more
> ports open:
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports
>  
> 
> 
> 
> 
> -- 
> Alexandre Pitre
> alexandre.pi...@gmail.com 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> 
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getcert and java certstore/keytool

[Jochen Hein via FreeIPA-users]

Jochen Hein via FreeIPA-users 
writes:

> Rob Crittenden via FreeIPA-users 
> writes:
>
>> So theoretically certmonger could for example, track PEM files in the
>> filesystem and upon renewal run a post script to import the updated cert
>> into the java keystore.
>
> This is my current script to get a cert from IPA, which is tracked by
> certmonger.  I've yet to test refreshing a certificate, but the steps
> manually did work (I expect some SELINUX woes...):

Exactly as I though, I got an AVC denied:

> # Get a certificate and key from IPA
> #ipa-getcert request -w -f /etc/pki/tls/certs/saml.example.org.crt \
> #   -k /etc/pki/tls/private/saml.example.org.key \
> #   -N CN=saml.example.org \
> #   -D saml.example.org \
> #   -K HTTP/saml.example.org -U 1.3.6.1.5.5.7.3.1
> ##   -C ""

type=AVC msg=audit(1502045477.106:1325): avc: denied { execute } for
pid=7057 comm="certmonger" name="refresh_keycloak_certificate"
dev="sda1" ino=36338210 scontext= system_u:system_r:certmonger_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

I stored my refresh script in /root and might have some luck with
chcon.  But is there a location, for example in /etc, that would give my
script the needed rights?  No examples I've looked at in the IdM manual
used -C and no discussion about selinux lables.

certmonger scripts are stored in /usr/libexec/ipa/certmonger and have:

# ls -lZ /usr/libexec/ipa/certmonger/restart_httpd
-rwxr-xr-x. root root system_u:object_r:bin_t:s0   
/usr/libexec/ipa/certmonger/restart_httpd

Once I label my script with bin_t I get more denials, so probably not
the right thing to do:

type=AVC msg=audit(1501563217.770:154): avc:  denied  { write } for  pid=12545 
comm="mkhomedir" name="lib" dev="vdc1" ino=131 
scontext=unconfined_u:unconfined_r:oddjob_mkhomedir_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:var_lib_t:s0 tclass=dir
type=AVC msg=audit(1501619025.994:1172): avc:  denied  { write } for  pid=15759 
comm="certmonger" name="configuration" dev="vda1" ino=17147456 
scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:usr_t:s0 
tclass=dir
type=AVC msg=audit(1501619132.710:1173): avc:  denied  { write } for  pid=15759 
comm="certmonger" name="configuration" dev="vda1" ino=17147456 
scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:usr_t:s0 
tclass=dir
type=AVC msg=audit(1501619192.323:1174): avc:  denied  { create } for  
pid=18555 comm="certmonger" name="saml.jochen.org.key" 
scontext=system_u:system_r:certmonger_t:s0 
tcontext=system_u:object_r:var_lib_t:s0 tclass=file
type=AVC msg=audit(1501619605.451:1182): avc:  denied  { write } for  pid=15759 
comm="certmonger" name="root" dev="vda1" ino=33595521 
scontext=system_u:system_r:certmonger_t:s0 
tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
type=AVC msg=audit(1501699449.127:2460): avc:  denied  { write } for  pid=15759 
comm="certmonger" name="root" dev="vda1" ino=33595521 
scontext=system_u:system_r:certmonger_t:s0 
tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
type=AVC msg=audit(1502045477.106:1325): avc:  denied  { execute } for  
pid=7057 comm="certmonger" name="refresh_keycloak_certificate" dev="sda1" 
ino=36338210 scontext=system_u:system_r:certmonger_t:s0 
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1502049392.796:1375): avc:  denied  { write } for  pid=3851 
comm="openssl" name="saml.jochen.org.key" dev="sda1" ino=18535953 
scontext=system_u:system_r:certmonger_t:s0 
tcontext=unconfined_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1502049392.799:1376): avc:  denied  { write } for  pid=3852 
comm="openssl" name="temp.p12" dev="sda1" ino=18535954 
scontext=system_u:system_r:certmonger_t:s0 
tcontext=unconfined_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1502049392.802:1377): avc:  denied  { read } for  pid=3854 
comm="keytool" name="cpu" dev="sysfs" ino=33 
scontext=system_u:system_r:certmonger_t:s0 
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

Is there some documentation where the admin should store his scripts and
how to label them that I missed?

I found certmonger_selinux, but that's too abstract for me. 

The (probably too big) hammer made it work for me:

# chcon -v --type=certmonger_unconfined_exec_t 
/root/refresh_keycloak_certificate

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Unable to SSH into Linux machine using AD user

[Supratik Goswami via FreeIPA-users]

Hi

I am using trust between AD and IPA

AD domain: ad.corp.example.com
IPA domain: ipa.corp.example.com

I am able to login using SSH to the IPA server using the AD user, when I am
trying to login using
SSH to the Linux client which is a member of the IPA domain it does not
work.

Please find my /etc/krb5.conf in the client machine below

[libdefaults]
  #default_realm = IPA.CORP.EXAMPLE.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  udp_preference_limit = 0
#  default_ccache_name = KEYRING:persistent:%{uid}


[realms]
  IPA.CORP.EXAMPLE.COM = {
kdc = ipa01.ipa.corp.example.com:88
master_kdc = ipa01.ipa.corp.example.com:88
admin_server = ipa01.ipa.corp.example.com:749
#default_domain = ipa.corp.example.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local = RULE:[1:$1@$0](^.*@AD.CORP.EXAMPLE.COM$)s/@
AD.CORP.EXAMPLE.COM/@ad.corp.example.com/
auth_to_local = DEFAULT

  }

  AD.CORP.EXAMPLE.COM = {
kdc = ad01.ad.corp.example.com:88
master_kdc = ad01.ad.corp.example.com:88
  }

[domain_realm]
 .ipa.corp.example.com = IPA.CORP.EXAMPLE.COM
 ipa.corp.example.com = IPA.CORP.EXAMPLE.COM
 .ad.corp.example.com = AD.CORP.EXAMPLE.COM
 ad.corp.example.com = AD.CORP.EXAMPLE.COM


Please find my SSD config below

[sssd]
config_file_version = 2
services = nss, sudo, pam, ssh
domains = ipa.corp.exampl.com

[nss]
homedir_substring = /home

[domain/ipa.corp.example.com]
debug_level = 9
krb5_store_password_if_offline = True
id_provider = ipa
auth_provider = ipa
access_provider = ipa
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.corp.example.com
ipa_hostname = host01.ipa.corp.example.com
ipa_server = _srv_, ipa01.ipa.corp.example.com
chpass_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
dns_discovery_domain = ipa.corp.example.com

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]


Please find the krb5_child.log attached.

Please help me to understand what I am missing here or what may be the
issue.

Thanks

-- 
Warm Regards

Supratik


krb5_child.log
Description: Binary data
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org