[Freeipa-users] Re: several IPA CA certificate entries

[Florence Blanc-Renaud via FreeIPA-users]

On 10/23/2017 08:59 PM, Bhavin Vaidya via FreeIPA-users wrote:

Hello Rob,


here what we have. Looks like /etc/http/alias certificate is different, 
as it is from Sug 03 2014 through Aug 03 2034, which is original date.


If /etc/httpd/alias does not contain the latest IPA CA certificate, 
running ipa-certupdate should fix this. The tool gets certificates from 
cn=certificates,cn=ipa,cn=etc,$BASEDN so you need to make sure that the 
latest one is present in this tree.


It will also update /etc/dirsrv/slapd-DOMxx, /etc/ipa/ca.crt and 
/etc/ipa/nssdb. It can be run on all IPA hosts (masters or clients).


Flo.



[root@ds01 alias]# certutil -L -d /etc/httpd/alias/

Certificate Nickname                                         Trust 
Attributes
 
  SSL,S/MIME,JAR/XPI


ipaCert                                                      u,u,u
Server-Cert                                                  u,u,u
EXAMPLE.COM IPA CA                                           CT,C,C

[root@ds01 alias]# certutil -d /etc/httpd/alias/ -L -n "EXAMPLE.COM IPA CA"
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 1 (0x1)
         Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
         Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
         Validity:
             Not Before: Sun Aug 03 19:28:18 2014
             Not After : Thu Aug 03 19:28:18 2034
         Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
         Subject Public Key Info:
             Public Key Algorithm: PKCS #1 RSA Encryption
             RSA Public Key:
                 Modulus:
                     c3:9d:33:68:81:3a:7e:83:15:ba:bd:54:1c:a3:28:6a:
                     

                 Exponent: 65537 (0x10001)
         Signed Extensions:
             Name: Certificate Authority Key Identifier
             Key ID:
                 48:da:13:cd:37:06:74:ac:
                 da:f7:6d:c6

             Name: Certificate Basic Constraints
             Critical: True
             Data: Is a CA with no maximum path length.

             Name: Certificate Key Usage
             Critical: True
             Usages: Digital Signature
                     Non-Repudiation
                     Certificate Signing
                     CRL Signing

             Name: Certificate Subject Key ID
             Data:
                 48:da:13:cd:37:06:74:ac:
                 da:f7:6d:c6

             Name: Authority Information Access
             Method: PKIX Online Certificate Status Protocol
             Location:
                 URI: "http://ipa01.example.com:80/ca/ocsp";

     Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
     Signature:
         7e:bb:1e:d8:f7:2c:57:45:57:2a:cb:a9:43:a9:1e:88:
         
     Fingerprint (SHA-256):
         64::1C
     Fingerprint (SHA1):
         28:How can we promote or update all the certificates on first master, then 
replica and client? Will we have to reboot or re-install client?


thank you and with regards,
Bhavin


*From:* Rob Crittenden 
*Sent:* Monday, October 23, 2017 11:14 AM
*To:* Anvar Kuchkartaev; Bhavin Vaidya via FreeIPA-users
*Cc:* John Dennis; Bhavin Vaidya
*Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
Anvar Kuchkartaev wrote:

Have you tried to add CA to systemwide database?


It gets added as part of ipa-client-install, after the point where it is
failing.

This leads me to believe you don't have the "right" CA certificate after
all.

Is your Apache web cert signed by the IPA CA or a 3rd party? If by IPA
then I'd compare the CA cert in the NSS db in /etc/httpd/alias with the
one you have in LDAP.

mod_nss won't let Apache start with a bad cert chain.

rob



Anvar Kuchkartaev 
an...@aegisnet.eu 
*From: *Bhavin Vaidya via FreeIPA-users

*Sent: *lunes, 23 de octubre de 2017 07:46 p.m.
*To: *Rob Crittenden; FreeIPA users list
*Reply To: *FreeIPA users list
*Cc: *John Dennis; Bhavin Vaidya
*Subject: *[Freeipa-users] Re: several IPA CA certificate entries


Thank you everyone.


We did manage to delete the certificates, all but the right one (we
figured out looking at clients' /etc/ipa/ca.crt)


But on client installation we now get different message, which is
related to certificate too. tried another IPA server too, same message.


Successfully retrieved CA cert
 Subject: CN=Certificate Authority,O=EXAMPLE.COM
 Issuer:  CN=Certificate Authority,O=EXAMPLE.COM
 Valid From:  Thu Jun 01 12:55:08 2017 UTC
 Valid Until: Mon Jun 01 12:55:08 2037 UTC

Joining realm failed: libcurl failed to execute the HTTP POST
transaction.  Peer certificate cannot be authenticated with known CA
certificates

Installation failed. Rolling back changes.
IPA client is not configured on this system.

I have attached the log file.

thank you all once again.
regards,
Bhavin






-

[Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

[Simo Sorce via FreeIPA-users]

On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the FreeIPA List,
> 
>  
> 
> We've got a FreeIPA directory set up and running. That's all good.
> 
>  
> 
> The difficult part is that we also have a number (many) of SLE 12 SP2
> hosts
> that need to be enrolled.
> 
>  
> 
> I can see that the freeipa-client package has not been available to
> SLE/SUSE
> since 2015 or so, so the ipa-client-install, ipa-join, and ipa-
> getkeytab
> tools are unavailable. They would be nice, we'd just do a check and
> execute
> it when host is redeployed to enroll and configure the host.
> 
>  
> 
> We've manage to figure out the static parts of the required
> configuration
> (/etc/nsswitch.conf /etc/sssd/sssd.conf and /etc/krb5.conf) as well
> as
> deploying the FreeIPA server's certificate to /etc/ipa/ca.crt. We can
> also
> enroll the hosts 'remotely' by scripting over their hostnames and IP
> addresses from a CSV file, so the exist in the FreeIPA directory and
> even
> join them to some hostgroups.
> 
>  
> 
> The bit we're a bit stuck at is retrieving the host's Kerberos
> keytab. There
> does not seem to be a getkeytab request for the FreeIPA API, and the
> use of
> kadmin and ktutil to process the keytab is not recommended.

Use ipa-getkeytab on an admin workstation, then securely transfer the
keytab to the servers.


> We need a stepwise process to run on the host being enrolled that
> gets the
> keytab from the FreeIPA directory and installs it into the host.
> 
>  
> 
> At the moment the method that looks like it's going to work is to
> write a
> script that ssh to the FreeIPA server, kinit as a user who can
> retrieve
> keytabs, get the keytab and write to a temporary file, scp the keytab
> back
> to the host, tidy up temp files, then return to the host, validate
> the
> keytab, install it, and restart Kerberos/sshd/sssd.

This may work also.

>  
> 
> This seems less than ideal, alternatively should we look a compiling
> the ipa-client into a package?

In the freeIPA git repo there is, in the spec file, a variable that
allows you to compile only the client bits IIRC. You should be able to
compile that for SLES.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: cross-forest trust, client system cannot id AD users.

[Steve Dainard via FreeIPA-users]

Hi Jakub,

As a follow up, you are correct - neither the primary group or wheel group
that existed in AD needed to be created in IPA.

Thanks

On Fri, Oct 20, 2017 at 1:01 AM, Jakub Hrozek  wrote:

> On Thu, Oct 19, 2017 at 05:34:41PM -0700, Steve Dainard wrote:
> > Thanks Jakub and Justin,
> >
> > It definitely is related to the wheel group. For a quick explanation, the
> > wheel group exists in AD with a gid of 10 so users who belong to that
> group
> > automatically have wheel/sudo perms on EL systems (we use posix
> attributes
> > in AD for all our users/groups).
> >
> > The easy fix seems to have been to add a wheel group with gid 10 to the
> IPA
> > side, no group members. Now I get:
> >  uid=1587(steve.dain...@addomain.com) gid=1028(employ...@ipadomain.zone)
> > groups=1028(employ...@ipadomain.zone),10(wheel),
> 1027(clus...@addomain.com
> > ),1029(sys...@addomain.com),1041(confluence-administrat...@addomain.com
> > ),1060(employees-vancou...@addomain.com),1086(dev...@addomain.com)
> > context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >
> > I got the idea from the RH IPA docs mentioning if a user has a primary
> > group in AD with a gid, the group must also exist in IPA albeit doesn't
> > need any members.
> > If this step isn't completed some secondary group
> > memberships may not be resolved on the IPA side.
>
> Maybe the docs are not totally clear, but the requirement is a bit
> different
> -- it is actually that each GID number the user is a member of (as reported
> by "id -G") must be resolvable into a group object with getgrgid() (or,
> with getent group $gidnumber) on the command line.
>
> >
> > Its still a bit odd that the wheel group appears to be a client local
> wheel
> > group rather than @IPADOMAIN.
>
> I think this is because /etc/nsswitch.conf defines "groups" as "files sss".
>
> So the initgroups operation returns a list of gids, which are then
> translated
> into names, but because files precedes sss, the local group name is used
> first.
>
> By the way, you might be interested in
> https://sourceware.org/glibc/wiki/Proposals/GroupMerging
>
> (I keep forgetting it this is already backported to RHEL-7, though..)
>
> > The 'employees@IPADOMAIN' group listed above
> > is actually the primary gid in AD Unix attributes, and is defined in IPA
> > with the same gid but has no members. I'm guess this is because an EL
> host
> > /etc/group defines 'wheel' by default, but not 'employees'.
> >
> > Once we get IPA into production I'll pull the wheel group out of AD and
> > keep it defined in IPA only.
> >
> > Thanks,
> > Steve
> >
> > On Thu, Oct 19, 2017 at 11:37 AM, Justin Stephenson via FreeIPA-users <
> > freeipa-users@lists.fedorahosted.org> wrote:
> >
> > > On 10/19/2017 02:14 PM, Jakub Hrozek via FreeIPA-users wrote:
> > >
> > >> On Tue, Oct 17, 2017 at 02:21:07PM -0700, Steve Dainard via
> FreeIPA-users
> > >> wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> I've installed a 60 day 'self supported' trial of red hat idm on
> rhel7.
> > >>> I've created a cross-forest trust with an AD domain (2012R2) which
> > >>> already
> > >>> has posix attributes in ldap for users and groups.
> > >>>
> > >>> On my ipa server I can id/getent my AD user, and can SSH to the ipa
> > >>> server
> > >>> with my AD credentials/kerberos ticket.
> > >>> # id steve.dain...@addomain.com
> > >>> uid=1587(steve.dain...@addomain.com) gid=1028(employees)
> > >>> groups=1028(employees),1041(confluence-administrat...@addomain.com
> > >>> ),1060(employees-vancou...@addomain.com),10(wheel),1027(clus
> > >>> t...@addomain.com
> > >>> ),1086(dev...@addomain.com),1029(sys...@addomain.com)
> > >>>
> > >>> I installed Centos 7.4 and joined it to the realm but I'm having
> > >>> intermittent issues id'ing users. At first I couldn't id any AD
> user, but
> > >>> then I added a trusted domain ldap_search_base to the ipa servers
> > >>> sssd.conf:
> > >>>
> > >>> ldap_search_base = OU=Employees,OU=Users,OU=
> Accounts,DC=ADDOMAIN,DC=com
> > >>>
> > >>> This initially seemed to work intermittently, some users I could id
> and
> > >>> some I could not. I also noticed that the group membership of the
> users I
> > >>> could id was incomplete, notably I have an AD group 'wheel' with gid
> 10
> > >>> that shows on the ipa server side when I id my AD user, but didn't
> show
> > >>> on
> > >>> the client side.
> > >>>
> > >>> I decided to clear out the cache files manually and restart sssd on
> the
> > >>> client, and now I can't id my user, but I can id users outside of the
> > >>> ldap_search_base, specifically user accounts which are inactive and
> exist
> > >>> in a inactive-users OU ouside the ldap_search_base. Very confusing.
> > >>>
> > >>> The sssd server side seems to be iterating through all my AD users
> > >>> account
> > >>> names in the logs (debug_level = 10) and I don't feel comfortable
> posting
> > >>> logs with their complete names online..
> > >>>
> > >>>
> > >>> IPA server sssd.conf:
> > >>>
> > >>> [doma

[Freeipa-users] ipa sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Alexandre Pitre via FreeIPA-users]

Hi,

I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple groups
with the sudorule-add-user command.

Example:

ipa sudorule-add-user sudorule --groups=group1,group2

 Failed users/groups:
member user:
member group: group1,group2
-
Number of members added 0
-

Other similar ipa commands support multiple groups just fine.

Is this normal ?

Thanks,
Alex
___
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 sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Rob Crittenden via FreeIPA-users]

Alexandre Pitre via FreeIPA-users wrote:
> Hi,
> 
> I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple
> groups with the sudorule-add-user command.
> 
> Example:
> 
> ipa sudorule-add-user sudorule --groups=group1,group2
> 
>  Failed users/groups:
> member user:
> member group: group1,group2
> -
> Number of members added 0
> -
> 
> Other similar ipa commands support multiple groups just fine.
> 
> Is this normal ?

CSV hasn't been supported for quite a long time. I'd be curious where it
is still working.

You can do let bash expand it instead:

ipa sudorule-add-user sudorule --groups={group1,group2}

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] IPA cross-forest trust, retrieve additional ldap attributes for users

[Steve Dainard via FreeIPA-users]

Hello,

I'm running a cross-forest trust with RHEL 7 IPA (60 day trial), when I do
an ldapsearch on the AD user against the IPA server I get very few
attributes.

It seems like the sssd option 'ldap_user_extras_attrs' should fetch
additional attributes but I can't seem to get any results. I'm also
confused which section this option should be added to on IPA server
sssd.conf. I've tried:

[domain/ipadomain]
ldap_user_extras_attrs = givenname, sn, displayname

[domain/addomain]
ldap_user_extras_attrs = givenname, sn, displayname

[domain/ipadomain/addomain]
ldap_user_extras_attrs = givenname, sn, displayname

Of note, I didn't include the 'mail' attribute as a value above as I read a
post that said IPA should pull this attribute automatically but I'm not
seeing it either when doing an ldapsearch. Maybe this points to a bigger
problem..

Here are the value's I'm receiving:
# steve.dain...@addomain.com, users, compat, ipadomain.com
dn: uid=steve.dain...@addomain.com,cn=users,cn=compat,dc=ipadomain,dc=com
objectClass: posixAccount
objectClass: top
gecos: Steve Dainard
cn: Steve Dainard
uidNumber: 1587
gidNumber: 1028
loginShell: /bin/sh
homeDirectory: /home/addomain.com/steve.dainard
uid: steve.dain...@addomain.com

The uidNumber/gidNumber are coming from AD, but the loginShell in AD is set
to /bin/bash.

I've also seen mention of using the [ifp] section to populate attributes
for applications such as manageiq
http://manageiq.org/docs/reference/euwe/auth/ipa_ad_trust but if I add that
option my client hosts can't id users. I'm not entirely sure if the [ifp]
entry should be server side, client side, or both.


Thanks,
Steve
___
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 CA allow CSR SAN names in external domains

[Steve Dainard via FreeIPA-users]

That did it, thanks Fraser.

On Fri, Oct 20, 2017 at 5:48 PM, Fraser Tweedale 
wrote:

> On Fri, Oct 20, 2017 at 10:59:36AM -0700, Steve Dainard via FreeIPA-users
> wrote:
> > Hello
> >
> > I have a RHEL7 IPA server installed as a subordinate CA. I'd like to be
> > able to add SAN's for a different dns domain than exists in the IPA
> realm.
> > The dns for 'otherdomain.com' is handled by active directory which my
> IPA
> > server has a cross-forest trust with.
> >
> > ie:
> > host: client1.ipadomain.com
> > certificate: CN = client1.ipadomain.com, SAN = client1.ipadomain.com,
> > servicename.otherdomain.com
> >
> > When I try to submit this CSR with 'ipa-getcert request' the IPA server
> > denies with: "The service principal for subject alt name
> > servicename.otherdomain.com in certificate request does not exist"
> >
> > It seems that the default CAACL enforces a profile named
> > 'caIPAserviceCert', but I'm having some trouble determining what can be
> > modified (or cloned and changed in a new profile) that would allow  the
> CA
> > to sign a CSR that contains *.ipadomain.com and *.otherdomain.com in the
> > SAN.
> >
> > This is the only section in the profile that contains SAN:
> > policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
> > policyset.serverCertSet.12.constraint.name=No Constraint
> > policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
> > policyset.serverCertSet.12.default.name=Copy Common Name to Subject
> > Alternative Name
> >
> > Thanks,
> > Steve
> >
> You can add a principal alias to the service principal:
>
>   % ipa service-add-principal HTTP/client1.ipadomain.com \
>   HTTP/servicename.otherdomain.com
>
> Then the CSR validation routine will see the
> `servicename.otherdomain.com' SAN dnsName as a valid SAN for the
> subject principal.
>
> (This feature was added in FreeIPA 4.5)
>
> Cheers,
> Fraser
>
___
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 cross-forest trust, retrieve additional ldap attributes for users

[Alexander Bokovoy via FreeIPA-users]

On ti, 24 loka 2017, Steve Dainard via FreeIPA-users wrote:

Hello,

I'm running a cross-forest trust with RHEL 7 IPA (60 day trial), when I do
an ldapsearch on the AD user against the IPA server I get very few
attributes.

It seems like the sssd option 'ldap_user_extras_attrs' should fetch
additional attributes but I can't seem to get any results. I'm also
confused which section this option should be added to on IPA server
sssd.conf. I've tried:

[domain/ipadomain]
ldap_user_extras_attrs = givenname, sn, displayname

[domain/addomain]
ldap_user_extras_attrs = givenname, sn, displayname

[domain/ipadomain/addomain]
ldap_user_extras_attrs = givenname, sn, displayname

Of note, I didn't include the 'mail' attribute as a value above as I read a
post that said IPA should pull this attribute automatically but I'm not
seeing it either when doing an ldapsearch. Maybe this points to a bigger
problem..

Yes, a problem of misunderstanding what piece is used for. ;)

SSSD retrieval of extended attributes is used by SSSD info pipe
interface which is available over DBus. There are applications like
Apache or nginx plugins that consume this interface. Schema
compatibility plugin in FreeIPA LDAP server (slapi-nis) is not using
this API and thus is not providing this information in records you see
in 'cn=compat,$SUFFIX' subtree.



--
/ Alexander Bokovoy
___
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 sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Alexandre Pitre via FreeIPA-users]

Would you look at that! Problem solved.Thanks.

On Tue, Oct 24, 2017 at 12:08 PM, Rob Crittenden 
wrote:

> Alexandre Pitre via FreeIPA-users wrote:
> > Hi,
> >
> > I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple
> > groups with the sudorule-add-user command.
> >
> > Example:
> >
> > ipa sudorule-add-user sudorule --groups=group1,group2
> >
> >  Failed users/groups:
> > member user:
> > member group: group1,group2
> > -
> > Number of members added 0
> > -
> >
> > Other similar ipa commands support multiple groups just fine.
> >
> > Is this normal ?
>
> CSV hasn't been supported for quite a long time. I'd be curious where it
> is still working.
>
> You can do let bash expand it instead:
>
> ipa sudorule-add-user sudorule --groups={group1,group2}
>
> rob
>



-- 
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] Re: Latest updates broke pki-tomcatd

[Kristian Petersen via FreeIPA-users]

You mentioned that once before, but that path doesn't seem to exist on my
server for some reason.  When I go to /var/log/pki i get:
-bash-4.2$ cd /var/log/pki/
-bash-4.2$ ls
pki-server-upgrade-10.4.1.log  pki-upgrade-10.4.1.log  server

In a previous reply, I ran a command you asked me to that showed some
information about the setup of our IPA server that you had requested that
you may need to look at.

On Thu, Oct 19, 2017 at 1:21 AM, Rob Crittenden  wrote:

> Kristian Petersen wrote:
>
>> I'm still struggling with this one and it seems at least partially
>> responsible for the UI misbehaving as we discussed in another thread.
>> Have you had any new insights regarding this?
>>
>
> I'd start with looking at /var/log/pki/pki-tomcat/ca/debug. You want to
> find the latest start and work down from there (rather than bottom up).
>
> rob
>
>
>> On Mon, Oct 9, 2017 at 3:54 PM, Kristian Petersen > > wrote:
>>
>> The installation is a standard RedHat IdM install with DNS, SMB, and
>> CA services installed.
>>
>> The output of the ldapsearch you mentioned is:
>> -bash-4.2$ ldapsearch -LLL -Y GSSAPI -b cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=edu
>>
>> SASL/GSSAPI authentication started
>> SASL username: nesre...@chem.byu.edu 
>> SASL SSF: 56
>> SASL data security layer installed.
>> dn: cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=edu
>>
>> ipaMaxDomainLevel: 1
>> ipaReplTopoManagedSuffix: dc=chem,dc=byu,dc=edu
>> ipaReplTopoManagedSuffix: o=ipaca
>> objectClass: top
>> objectClass: nsContainer
>> objectClass: ipaConfigObject
>> objectClass: ipaSupportedDomainLevelConfig
>> objectClass: ipaReplTopoManagedServer
>> cn: ipa1.chem.byu.edu 
>> ipaMinDomainLevel: 0
>>
>> dn: cn=CA,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=edu
>>
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: enabledService
>> ipaConfigString: startOrder 50
>> ipaConfigString: caRenewalMaster
>> cn: CA
>>
>> dn: cn=KDC,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=edu
>>
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: startOrder 10
>> ipaConfigString: enabledService
>> ipaConfigString: kdcProxyEnabled
>> ipaConfigString: pkinitEnabled
>> cn: KDC
>>
>> dn: cn=KPASSWD,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc
>> =edu
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: enabledService
>> ipaConfigString: startOrder 20
>> cn: KPASSWD
>>
>> dn: cn=MEMCACHE,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,d
>> c=edu
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: startOrder 39
>> ipaConfigString: enabledService
>> cn: MEMCACHE
>>
>> dn: cn=OTPD,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=ed
>>
>> u
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: startOrder 80
>> ipaConfigString: enabledService
>> cn: OTPD
>>
>> dn: cn=HTTP,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=ed
>>
>> u
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: startOrder 40
>> ipaConfigString: enabledService
>> cn: HTTP
>>
>> dn: cn=DNS,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=edu
>>
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: startOrder 30
>> ipaConfigString: enabledService
>> cn: DNS
>>
>> dn: cn=ADTRUST,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc
>> =edu
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: startOrder 60
>> ipaConfigString: enabledService
>> cn: ADTRUST
>>
>> dn: cn=EXTID,cn=ipa1.chem.byu.edu
>> ,cn=masters,cn=ipa,cn=etc,dc=chem,
>> dc=byu,dc=e
>> du
>> objectClass: ipaConfigObject
>> objectClass: nsContainer
>> objectClass: top
>> ipaConfigString: startOrder 70
>> ipaConfigString: enabledService
>> cn: EXTID
>>
>> dn: cn=DNSKeySync,cn=ipa1.ch

[Freeipa-users] Re: Latest updates broke pki-tomcatd

[Rob Crittenden via FreeIPA-users]

Kristian Petersen via FreeIPA-users wrote:
> You mentioned that once before, but that path doesn't seem to exist on
> my server for some reason.  When I go to /var/log/pki i get:
> -bash-4.2$ cd /var/log/pki/ 
> -bash-4.2$ ls 
> pki-server-upgrade-10.4.1.log  pki-upgrade-10.4.1.log  server
> 
> In a previous reply, I ran a command you asked me to that showed some
> information about the setup of our IPA server that you had requested
> that you may need to look at.

Then you don't have a CA installed on this host. This is where the logs
would be on a 4.5.0 server. You can try something like find /var/log
-name debug in case this was an oft-upgraded server and the path is for
an older release.

rob

> 
> On Thu, Oct 19, 2017 at 1:21 AM, Rob Crittenden  > wrote:
> 
> Kristian Petersen wrote:
> 
> I'm still struggling with this one and it seems at least partially
> responsible for the UI misbehaving as we discussed in another
> thread.
> Have you had any new insights regarding this?
> 
> 
> I'd start with looking at /var/log/pki/pki-tomcat/ca/debug. You want
> to find the latest start and work down from there (rather than
> bottom up).
> 
> rob
> 
> 
> On Mon, Oct 9, 2017 at 3:54 PM, Kristian Petersen
> mailto:nesre...@chem.byu.edu>
> >>
> wrote:
> 
> The installation is a standard RedHat IdM install with DNS,
> SMB, and
> CA services installed.
> 
> The output of the ldapsearch you mentioned is:
> -bash-4.2$ ldapsearch -LLL -Y GSSAPI -b cn=ipa1.chem.byu.edu
> 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> SASL/GSSAPI authentication started
> SASL username: nesre...@chem.byu.edu
>   >
> SASL SSF: 56
> SASL data security layer installed.
> dn: cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> ipaMaxDomainLevel: 1
> ipaReplTopoManagedSuffix: dc=chem,dc=byu,dc=edu
> ipaReplTopoManagedSuffix: o=ipaca
> objectClass: top
> objectClass: nsContainer
> objectClass: ipaConfigObject
> objectClass: ipaSupportedDomainLevelConfig
> objectClass: ipaReplTopoManagedServer
> cn: ipa1.chem.byu.edu 
> 
> ipaMinDomainLevel: 0
> 
> dn: cn=CA,cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: enabledService
> ipaConfigString: startOrder 50
> ipaConfigString: caRenewalMaster
> cn: CA
> 
> dn: cn=KDC,cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: startOrder 10
> ipaConfigString: enabledService
> ipaConfigString: kdcProxyEnabled
> ipaConfigString: pkinitEnabled
> cn: KDC
> 
> dn: cn=KPASSWD,cn=ipa1.chem.byu.edu 
>
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc
> =edu
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: enabledService
> ipaConfigString: startOrder 20
> cn: KPASSWD
> 
> dn: cn=MEMCACHE,cn=ipa1.chem.byu.edu 
>
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,d
> c=edu
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: startOrder 39
> ipaConfigString: enabledService
> cn: MEMCACHE
> 
> dn: cn=OTPD,cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=ed
> 
> u
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: startOrder 80
> ipaConfigString: enabled

[Freeipa-users] Install replica

[Oleg Danilovich via FreeIPA-users]

Hello guys,
I want deploy freeipa replica. Now my master works on Ubuntu 16.04. Master
version VERSION: 4.3.1, API_VERSION: 2.164
Then i try to install replica on ubuntu i get error. I tried to find a
solution but could not.
I want try to install freeipa replica on centos. Can i use freeipa replica
on centos then my master on Ubuntu 16.04 ?

-- 
Best regards,
*Oleg Danilovich*

DevOps Engineer
*exp**(capital) **limited*

*T.  **+ <+357%2096%20672275>375447487939*
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] yum update caused FreeIPA to temporarily return NXDOMAIN for valid records

[Nicholas Hinds via FreeIPA-users]

During an upgrade from 4.5.0-21.el7.centos.1.2 to 4.5.0-21.el7.centos.2.2
on a CentOS 7.4 machine, FreeIPA's DNS server briefly returned NXDOMAIN for
records which existed in FreeIPA. These invalid responses were returned for
a very short amount of time, but caused long-running issues with Java
clients which tend to cache DNS responses. Upgraded packages included:
389-ds-base, 389-ds-base-libs, 389-ds-base-snmp, ipa-client,
ipa-client-common, ipa-python-compat, ipa-server, ipa-server-common,
ipa-server-dns, ipa-server-trust-ad, python2-ipa-server, and a dozen
sss-related packages.

I reproduced this in a FreeIPA test environment by running `while true; do
dig some.dns.entry.managed.by.freeipa @ip.address.of.freeipa | tee -a
a-log-file; done` from one server, and running `yum update` on the FreeIPA
machine. The invalid NXDOMAIN responses were returned some time after the
`yum update` logged 'Cleanup' for the RPMs, and seemed to be during the
'Verifying' phase.

These NXDOMAIN responses claimed that an upstream nameserver (
a.root-servers.net) was the authority for my zone:

a-log-file-; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
some.dns.entry.managed.by.freeipa @172.16.0.77
a-log-file-;; global options: +cmd
a-log-file-;; Got answer:
a-log-file:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2889
a-log-file-;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0
a-log-file-
a-log-file-;; QUESTION SECTION:
a-log-file-;some.dns.entry.managed.by.freeipa. IN A
a-log-file-
a-log-file-;; AUTHORITY SECTION:
a-log-file-. 60 IN SOA a.root-servers.net. nstld.verisign-grs.com.
2017102400 1800 900 604800 86400
a-log-file-
a-log-file-;; Query time: 227 msec
a-log-file-;; SERVER: 172.16.0.77#53(172.16.0.77)
a-log-file-;; WHEN: Tue Oct 24 18:30:28 2017
a-log-file-;; MSG SIZE  rcvd: 130

Usually when querying an invalid DNS entry, the dig output still claims
that my FreeIPA server is authoritative for the zone:
$ dig doesntexist.zone.managed.by.freeipa @172.16.0.77

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
doesntexist.zone.managed.by.freeipa @172.16.0.77
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59953
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;doesntexist.zone.managed.by.freeipa. IN A

;; AUTHORITY SECTION:
zone.managed.by.freeipa. 30 IN SOA idm01.freeipa.
hostmaster.zone.managed.by.freeipa. 1508869828 30 900 1209600 30

;; Query time: 0 msec
;; SERVER: 172.16.0.77#53(172.16.0.77)
;; WHEN: Tue Oct 24 19:27:12 2017
;; MSG SIZE  rcvd: 113


Is it possible that during a yum update, the FreeIPA DNS server temporarily
forgets what zones it's authoritative for (or forgets all DNS records) and
just delegates to the upstream DNS server for half a second or so? Or is
something else going on here?

I'm open to suggestions.


Thanks,
Nicholas.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Install replica

[Rob Crittenden via FreeIPA-users]

Oleg Danilovich via FreeIPA-users wrote:
> Hello guys, 
> I want deploy freeipa replica. Now my master works on Ubuntu 16.04.
> Master version VERSION: 4.3.1, API_VERSION: 2.164
> Then i try to install replica on ubuntu i get error. I tried to find a
> solution but could not. 

It would help if you told us what error you saw.

> I want try to install freeipa replica on centos. Can i use freeipa
> replica on centos then my master on Ubuntu 16.04 ? 

Yes that should work.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: yum update caused FreeIPA to temporarily return NXDOMAIN for valid records

[Rob Crittenden via FreeIPA-users]

Nicholas Hinds via FreeIPA-users wrote:
> During an upgrade from 4.5.0-21.el7.centos.1.2
> to 4.5.0-21.el7.centos.2.2 on a CentOS 7.4 machine, FreeIPA's DNS server
> briefly returned NXDOMAIN for records which existed in FreeIPA. These
> invalid responses were returned for a very short amount of time, but
> caused long-running issues with Java clients which tend to cache DNS
> responses. Upgraded packages included: 389-ds-base, 389-ds-base-libs,
> 389-ds-base-snmp, ipa-client, ipa-client-common, ipa-python-compat,
> ipa-server, ipa-server-common, ipa-server-dns, ipa-server-trust-ad,
> python2-ipa-server, and a dozen sss-related packages.
> 
> I reproduced this in a FreeIPA test environment by running `while true;
> do dig some.dns.entry.managed.by.freeipa @ip.address.of.freeipa | tee -a
> a-log-file; done` from one server, and running `yum update` on the
> FreeIPA machine. The invalid NXDOMAIN responses were returned some time
> after the `yum update` logged 'Cleanup' for the RPMs, and seemed to be
> during the 'Verifying' phase.
> 
> These NXDOMAIN responses claimed that an upstream nameserver
> (a.root-servers.net ) was the authority for
> my zone:
> 
> a-log-file-; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
> some.dns.entry.managed.by.freeipa @172.16.0.77 
> a-log-file-;; global options: +cmd
> a-log-file-;; Got answer:
> a-log-file:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2889
> a-log-file-;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
> ADDITIONAL: 0
> a-log-file-
> a-log-file-;; QUESTION SECTION:
> a-log-file-;some.dns.entry.managed.by.freeipa. IN A
> a-log-file-
> a-log-file-;; AUTHORITY SECTION:
> a-log-file-.60INSOAa.root-servers.net .
> nstld.verisign-grs.com . 2017102400 1800
> 900 604800 86400
> a-log-file-
> a-log-file-;; Query time: 227 msec
> a-log-file-;; SERVER: 172.16.0.77#53(172.16.0.77)
> a-log-file-;; WHEN: Tue Oct 24 18:30:28 2017
> a-log-file-;; MSG SIZE  rcvd: 130
> 
> Usually when querying an invalid DNS entry, the dig output still claims
> that my FreeIPA server is authoritative for the zone:
> $ dig doesntexist.zone.managed.by.freeipa @172.16.0.77 
> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
> doesntexist.zone.managed.by.freeipa @172.16.0.77 
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59953
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;doesntexist.zone.managed.by.freeipa. IN A
> 
> ;; AUTHORITY SECTION:
> zone.managed.by.freeipa.30 INSOAidm01.freeipa.
> hostmaster.zone.managed.by.freeipa. 1508869828 30 900 1209600 30
> 
> ;; Query time: 0 msec
> ;; SERVER: 172.16.0.77#53(172.16.0.77)
> ;; WHEN: Tue Oct 24 19:27:12 2017
> ;; MSG SIZE  rcvd: 113
> 
> 
> Is it possible that during a yum update, the FreeIPA DNS server
> temporarily forgets what zones it's authoritative for (or forgets all
> DNS records) and just delegates to the upstream DNS server for half a
> second or so? Or is something else going on here?
> 
> I'm open to suggestions.

The LDAP server is brought down during upgrades which is likely the
issue. bind can't connect to its backend. Why it returns NXDOMAIN I
don't know.

You may be able to manually work around this by manually stopping bind
before updating IPA, then starting it again afterwards.

rob
___
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 cross-forest trust, retrieve additional ldap attributes for users

[Steve Dainard via FreeIPA-users]

Hi Alexander,

That makes sense, is there a simple method to test which
ldap_user_extras_attrs sssd is pulling in on the IPA server side (are we
actually pulling in these attributes), and then test from the client side
dbus (list said attributes)?

Thanks,
Steve

On Tue, Oct 24, 2017 at 9:30 AM, Alexander Bokovoy 
wrote:

> On ti, 24 loka 2017, Steve Dainard via FreeIPA-users wrote:
>
>> Hello,
>>
>> I'm running a cross-forest trust with RHEL 7 IPA (60 day trial), when I do
>> an ldapsearch on the AD user against the IPA server I get very few
>> attributes.
>>
>> It seems like the sssd option 'ldap_user_extras_attrs' should fetch
>> additional attributes but I can't seem to get any results. I'm also
>> confused which section this option should be added to on IPA server
>> sssd.conf. I've tried:
>>
>> [domain/ipadomain]
>> ldap_user_extras_attrs = givenname, sn, displayname
>>
>> [domain/addomain]
>> ldap_user_extras_attrs = givenname, sn, displayname
>>
>> [domain/ipadomain/addomain]
>> ldap_user_extras_attrs = givenname, sn, displayname
>>
>> Of note, I didn't include the 'mail' attribute as a value above as I read
>> a
>> post that said IPA should pull this attribute automatically but I'm not
>> seeing it either when doing an ldapsearch. Maybe this points to a bigger
>> problem..
>>
> Yes, a problem of misunderstanding what piece is used for. ;)
>
> SSSD retrieval of extended attributes is used by SSSD info pipe
> interface which is available over DBus. There are applications like
> Apache or nginx plugins that consume this interface. Schema
> compatibility plugin in FreeIPA LDAP server (slapi-nis) is not using
> this API and thus is not providing this information in records you see
> in 'cn=compat,$SUFFIX' subtree.
>
>
>
> --
> / Alexander Bokovoy
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

[Aaron Hicks via FreeIPA-users]

Hi Simo,

> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
> to the servers.

We have _many_ hosts in a cluster, so this is not practical on a per host 
basis. I single line command we could bulk execute on each of them to retrieve 
the key would be preferred.

Regards,

Aaron

-Original Message-
From: Simo Sorce [mailto:s...@redhat.com] 
Sent: Wednesday, 25 October 2017 2:26 AM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Enrolling SLE 12 SP2 hosts with FreeIPA

On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the FreeIPA List,
> 
>  
> 
> We've got a FreeIPA directory set up and running. That's all good.
> 
>  
> 
> The difficult part is that we also have a number (many) of SLE 12 SP2 
> hosts that need to be enrolled.
> 
>  
> 
> I can see that the freeipa-client package has not been available to 
> SLE/SUSE since 2015 or so, so the ipa-client-install, ipa-join, and 
> ipa- getkeytab tools are unavailable. They would be nice, we'd just do 
> a check and execute it when host is redeployed to enroll and configure 
> the host.
> 
>  
> 
> We've manage to figure out the static parts of the required 
> configuration (/etc/nsswitch.conf /etc/sssd/sssd.conf and 
> /etc/krb5.conf) as well as deploying the FreeIPA server's certificate 
> to /etc/ipa/ca.crt. We can also enroll the hosts 'remotely' by 
> scripting over their hostnames and IP addresses from a CSV file, so 
> the exist in the FreeIPA directory and even join them to some 
> hostgroups.
> 
>  
> 
> The bit we're a bit stuck at is retrieving the host's Kerberos keytab. 
> There does not seem to be a getkeytab request for the FreeIPA API, and 
> the use of kadmin and ktutil to process the keytab is not recommended.

Use ipa-getkeytab on an admin workstation, then securely transfer the keytab to 
the servers.


> We need a stepwise process to run on the host being enrolled that gets 
> the keytab from the FreeIPA directory and installs it into the host.
> 
>  
> 
> At the moment the method that looks like it's going to work is to 
> write a script that ssh to the FreeIPA server, kinit as a user who can 
> retrieve keytabs, get the keytab and write to a temporary file, scp 
> the keytab back to the host, tidy up temp files, then return to the 
> host, validate the keytab, install it, and restart Kerberos/sshd/sssd.

This may work also.

>  
> 
> This seems less than ideal, alternatively should we look a compiling 
> the ipa-client into a package?

In the freeIPA git repo there is, in the spec file, a variable that allows you 
to compile only the client bits IIRC. You should be able to compile that for 
SLES.

Simo.

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
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 cross-forest trust, retrieve additional ldap attributes for users

[Alexander Bokovoy via FreeIPA-users]

On ti, 24 loka 2017, Steve Dainard wrote:

Hi Alexander,

That makes sense, is there a simple method to test which
ldap_user_extras_attrs sssd is pulling in on the IPA server side (are we
actually pulling in these attributes), and then test from the client side
dbus (list said attributes)?

See Stephen's blog, first part ("Configuring SSSD") has a good example
how to access SSSD infopipe with a command line:
https://sgallagh.wordpress.com/2016/05/27/openshift-and-sssd-part-3-extended-ldap-attributes/


--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

[Rob Crittenden via FreeIPA-users]

Aaron Hicks via FreeIPA-users wrote:
> Hi Simo,
> 
>> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
>> to the servers.
> 
> We have _many_ hosts in a cluster, so this is not practical on a per host 
> basis. I single line command we could bulk execute on each of them to 
> retrieve the key would be preferred.

Your best bet is to get ipa-client built for SLE.

rob

> 
> Regards,
> 
> Aaron
> 
> -Original Message-
> From: Simo Sorce [mailto:s...@redhat.com] 
> Sent: Wednesday, 25 October 2017 2:26 AM
> To: FreeIPA users list 
> Cc: Aaron Hicks 
> Subject: Re: [Freeipa-users] Enrolling SLE 12 SP2 hosts with FreeIPA
> 
> On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
>> Hello the FreeIPA List,
>>
>>  
>>
>> We've got a FreeIPA directory set up and running. That's all good.
>>
>>  
>>
>> The difficult part is that we also have a number (many) of SLE 12 SP2 
>> hosts that need to be enrolled.
>>
>>  
>>
>> I can see that the freeipa-client package has not been available to 
>> SLE/SUSE since 2015 or so, so the ipa-client-install, ipa-join, and 
>> ipa- getkeytab tools are unavailable. They would be nice, we'd just do 
>> a check and execute it when host is redeployed to enroll and configure 
>> the host.
>>
>>  
>>
>> We've manage to figure out the static parts of the required 
>> configuration (/etc/nsswitch.conf /etc/sssd/sssd.conf and 
>> /etc/krb5.conf) as well as deploying the FreeIPA server's certificate 
>> to /etc/ipa/ca.crt. We can also enroll the hosts 'remotely' by 
>> scripting over their hostnames and IP addresses from a CSV file, so 
>> the exist in the FreeIPA directory and even join them to some 
>> hostgroups.
>>
>>  
>>
>> The bit we're a bit stuck at is retrieving the host's Kerberos keytab. 
>> There does not seem to be a getkeytab request for the FreeIPA API, and 
>> the use of kadmin and ktutil to process the keytab is not recommended.
> 
> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
> to the servers.
> 
> 
>> We need a stepwise process to run on the host being enrolled that gets 
>> the keytab from the FreeIPA directory and installs it into the host.
>>
>>  
>>
>> At the moment the method that looks like it's going to work is to 
>> write a script that ssh to the FreeIPA server, kinit as a user who can 
>> retrieve keytabs, get the keytab and write to a temporary file, scp 
>> the keytab back to the host, tidy up temp files, then return to the 
>> host, validate the keytab, install it, and restart Kerberos/sshd/sssd.
> 
> This may work also.
> 
>>  
>>
>> This seems less than ideal, alternatively should we look a compiling 
>> the ipa-client into a package?
> 
> In the freeIPA git repo there is, in the spec file, a variable that allows 
> you to compile only the client bits IIRC. You should be able to compile that 
> for SLES.
> 
> Simo.
> 
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> 
> ___
> 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] nfsidmap/nss_getpwnam fails to resolve users with IPA/NFSv4+krb5

[Robert Sturrock via FreeIPA-users]

Hi All.

We have IPA setup in an AD trust to support our Linux fleet.  I’m running into 
a problem trying to get Ubuntu (16.04) clients to resolve names/ids on an 
NFS-mounted filesystem from an NFS server using NFSv4/krb5.  Files and 
directories show up as ‘nobody’ or an incorrect numerical ID when listed with 
‘ls’.  RHEL7 clients seem to working fine with a very similar configuration (as 
far as I can tell).

The particulars are:

  - AD forest has domains ‘localdomain’ and ‘student.localdomain’ (my user 
identity is ‘user@localdomain’)
  - IPA domain is ‘ipa.localdomain’
  - The NFS server (RHEL7) and clients (Ubu16.04, RHEL7) are both enrolled to 
IPA (with 'Domain=ipa.localdomain’ in /etc/idmapd.conf).

I have mounted the NFS volume on the clients with a simple:

  mount -t nfs4 nfs-server.ipa.localdomain:/export /mnt

Listing my directory as myself (‘rns@localdomain’) on the Ubuntu client, I see:

$ ls -ld rns
drwx-- 18 nobody 4294967294 4096 Oct 25 15:18 rns

.. with these corresponding nfsidmap messages:

Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: key: 
0x2c254c26 type: uid value: rns@localdomain@ipa.localdomain timeout 600
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: 
nfs4_name_to_uid: calling nsswitch->name_to_uid
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: 
nss_getpwnam: name 'rns@localdomain@ipa.localdomain' domain 'ipa.localdomain': 
resulting localname '(null)'
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: 
nss_getpwnam: name 'rns@localdomain@ipa.localdomain' does not map into domain 
'ipa.localdomain'
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: 
nfs4_name_to_uid: nsswitch->name_to_uid returned -22
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: 
nfs4_name_to_uid: final return value is -22

.. whereas on the RHEL7 client, I see:

$ ls -ld rns
drwx--. 18 rns@localdomain rns@localdomain 4096 Oct 25 15:18 rns

Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: key: 0xf113fd2 
type: uid value: rns@localdomain@ipa.localdomain timeout 600
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: 
nfs4_name_to_uid: calling nsswitch->name_to_uid
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nss_getpwnam: 
name 'rns@localdomain@ipa.localdomain' domain 'ipa.localdomain': resulting 
localname 'rns@localdomain'
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: 
nfs4_name_to_uid: nsswitch->name_to_uid returned 0
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: 
nfs4_name_to_uid: final return value is 0
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: key: 0x2125a5d2 
type: gid value: rns@localdomain@ipa.localdomain timeout 600
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: 
nfs4_name_to_gid: calling nsswitch->name_to_gid
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: 
nfs4_name_to_gid: nsswitch->name_to_gid returned 0
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: 
nfs4_name_to_gid: final return value is 0

Why does the Ubuntu client's nfsidmap think that my identity doesn’t map into 
‘ipa.localdomain’ and therefore (presumably) returns the error code ‘-22’?

(My identity resolves ok from the shell, using ‘id rns@localdomain’ and I can 
login and use local filesystems without issue).

The idmapd.conf looks like this:

[General]

Verbosity = 4
Pipefs-Directory = /run/rpc_pipefs

Domain = ipa.localdomain
Local-Realms = LOCALDOMAIN, STUDENT.LOCALDOMAIN, IPA.LOCALDOMAIN

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

Any pointers appreciated!

Regards,

Robert.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org