[Freeipa-users] Re: CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger

[Kevin Vasko via FreeIPA-users]

Melissa,I’ve been following your thread here as I also have a 4.5.x system that _really_ needs to be updated, but I’m nervous to touch it since it “works”.How you testing this without breaking the instance? Im nervous I have issues like you are experiencing and it breaks everything. I would like to test and validate that the upgrade works before going all in. Care to share your process?-KevinOn Feb 5, 2024, at 7:21 AM, Melissa Ferreira da Silva Boiko via FreeIPA-users  wrote:Thanks for the suggestion!I spun a new CentOS 7 image with 7.9.2009 / FreeIPA 4.6.8 (which involved setting up the incus server to cgroups v1).  Then I tried creating a replica from the 4.5.  It again broke on pki-tomcatd, but with a somewhat baffling error that I didn't know what to do about:      [3/30]: creating ACIs for admin      [4/30]: creating installation admin user      [5/30]: configuring certificate server instance      [error] IOError: [Errno 13] Permission denied: '/tmp/tmpRJcwYV'    Your system may be partly configured.    Run /usr/sbin/ipa-server-install --uninstall to clean up.This appears to be related tohttps://bugzilla.redhat.com/show_bug.cgi?id=1677027Which apparently was fixed on FreeIPA 4.7.I couldn't find a release with 4.7 so I tried again with a VM with CentOS 8-Stream, which is supposed to have 4.9.  Only yum/dnf couldn't find the ipa-server package at all; they'd list ipa-client, but not server.  I'm not familiar with RPM-based systems so it took a lot of digging (including trying my hand at Rocky Linux and localinstall from manual RPM downloads, which led to problems with dependencies) until I found out I had to add module_hotfixes=1 in the appstream.repo file.With FreeIPA 4.9 once again the CA setup failed, with a new error:  [28/30]: importing IPA certificate profilesLookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA.Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA.  [error] RemoteRetrieveError: Failed to authenticate to CA REST APIYour system may be partly configured.Run /usr/sbin/ipa-server-install --uninstall to clean up.There were some hard-to-read HTTP errors on the install log so I was already getting ready to give up and try to create a replica from Docker or something.  But just as a hail-mary I run the uninstall scripts, rebooted, and tried again, and to my surprise this time pki-tomcatd install worked!  I got a warning then on the KDC step:Configuring Kerberos KDC (krb5kdc)  [1/1]: installing X509 Certificate for PKINITPKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Server at https://vm-ipa-half-3.intra.viaboxxsystems.de/ipa/json failed request, will retry: 4035 (Request failed with status 500: Non-2xx response from CA REST API: 500. ).)Failed to configure PKINITFull PKINIT configuration did not succeedThe setup will only install bits essential to the server functionalityYou can enable PKINIT after the setup completed using 'ipa-pkinit-manage'But ipa-replica-install finished with status: successful for the first time, and "ipa-pkinit-manage enable" worked.  I now have a FreeIPA 4.9.13 replica with CA; hopefully 4.11 will replicate from that without issues and then I can promote it to primary CA.---In summary, these are the issues I found so far trying to upgrade from FreeIPA 4.5.0:Upgrade FreeIPA 4.5 / CentOS7 to the last CentOS 7 / FreeIPA 4.6: breaks due to certmonger timeout.Replicate to current FreeIPA 4.11 / Fedora 39: breaks due to hash incompatibility.Replicate to FreeIPA 4.6 / fresh CentOS 7: breaks due to systemd /tmp permissions error.Replicate to FreeIPA 4.7: couldn't find lxc containers with this version.Replicate to Freeipa 4.9 / CentOS 8-Stream: had to downgrade incus host to cgroups v1; first couple attempts failed, but eventually it worked.[]sAm Do., 1. Feb. 2024 um 17:07 Uhr schrieb Rob Crittenden :Melissa Ferreira da Silva Boiko via FreeIPA-users wrote:
> Hello all.
> 
> I'm trying to replace an ancient FreeIPA 4.5.0 master (and primary CA
> master) on CentOS 7.4.  I am having problems trying to make replicas
> with FreeIPA 4.11, and past threads suggest the errors are due to
> incompatibility of password hash algorithms, which are supposed to be
> fixed on the older releases rather than the newer.
> 
> Therefore I'm trying to upgrade the old server to the current version in
> the CentOS 7 repos, 4.6.8, to try to create fresh replicas from there. 
> But I'm having issues with the certmonger systemd service hanging, and
> breaking ipa-server-upgrade--whether I update the whole CentOS to
> 7.9.2009, or just ipa-server and its dependencies, the result is the same.
> 
> This is where ipa-server-upgrade breaks:
> 
>         [Verifying that root certificate is published]
>         [Migrate CRL publish directory]
>         CRL tree already moved
>         [Verifying that CA proxy configuration is correct]
>         IPA server upgrade failed: Inspect 

[Freeipa-users] Re: FreeIPA and TrueNAS Scale for mounting of nfs4 shares

[Kevin Vasko via FreeIPA-users]

I actually did this recently.

Full working settings configuration in TrueNAS Scale. You will need to
create a BIND account which I used "svcbind". The Aux Parameters are
extremely important otherwise your groups won't work correctly.

Directory Services
1. Hostname: ipa.site.example.com
2. Base DN: dc=site,dc=example,dc=com
3. Bind DN: uid=svcbind,cn=users,cn=accounts,dc=site,dc=example,dc=com
4. Bind Password: 
5. Kerberos Realm: SITE.EXAMPLE.COM
6. Kerberos Principal: nfs/.site.example@site.example.com
7. LDAP Timeout: 10
8. DNS Timeout: 10
9. Enable: [ x ]
10. Auxiliary Parameters
```
base passwd cn=users,cn=accounts,dc=site,dc=example,dc=com
base group cn=groups,cn=accounts,dc=site,dc=example,dc=com
```
11. encryption Mode: off
12. Schema: RFC2307BIS
13. Validate Certificates: [x]

1. Advanced Settings
1. Idmap
1. Idmap Backend: LDAP
2. DNS Domain Name: site.example.com
3. Range Low: 10001
4. Range High: 20
5. Base DN: dc=site,dc=example,dc=com
6. LDAP User DN: uid=svcbind,cn=users,cn=accounts,dc=site,dc=example,dc=com
7. LDAP User DN Password: 
8. URL: ipa.site.example.com
2. Kerberos Realms
1. Realm: SITE.EXAMPLE.COM
2. KDC: ipa.site.example.com
3. Admin Servers: ipa.site.example.com
3. Kerberos Settings:
1. Libdefaults Auxiliary Parameters
```
default_realm = SITE.EXAMPLE.COM
dns_lookup_kdc = true
allow_weak_crypto = true
4. Kerberos KeyTab
1. Name: .site.example.com.keytab
2. Add IPA Host
1.  `ipa host-add nas-server.site.example.com --ip-address 10.75.37.2`
3. Add service
1.  `ipa service-add NFS/emc-nas-server.site.example@site.example.com
4. Generate Keytab
1.  `ipa-getkeytab -s ipaserver.example.com -p nfs/
emc-nas-server.site.example.com -k /tmp/emc-nas-server.keytab`
5. Upload to TrueNAS

I'm not sure of the idmap settings if they are actually useful but
everything worked even though we have overlapping IDs (which TrueNas Scale
complains about).

Helpful Link:
https://www.freeipa.org/page/Howto/Integrating_Dell_EMC_Unity

On Tue, Oct 3, 2023 at 5:23 AM Francis Augusto Medeiros-Logeay via
FreeIPA-users  wrote:

>
>
> On 3 Oct 2023, at 11:50, Alexander Bokovoy  wrote:
>
> On Аўт, 03 кас 2023, Francis Augusto Medeiros-Logeay via FreeIPA-users
> wrote:
>
>
>
> On 2 Oct 2023, at 15:12, Kees Bakker via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> On 02-10-2023 09:40, Francis Augusto Medeiros-Logeay via FreeIPA-users
> wrote:
>
> Hi,
>
> Has anyone here configured a TrueNAS joined to FreeIPA to share NFSv4
> shares with kerberos?
>
> I manage to mount the shares, the folder seems to have the right
> permissions, but I get permission denied when trying to access the folder.
>
> I am trying from a Fedora 37 client.
>
> As this is potentially off-topic, I’d be glad to take the discussion
> off-list.
>
>
> That's a very interesting subject. Just today we started looking at the
> same thing.
> I have no idea yet how to do this, so I too would like to know if somebody
> has succeeded to set this up.
> --
> Kees
>
>
> Great! If it is ok with you, please keep in touch to share how/what you
> accomplish.
>
> Here, I have managed to join TrueNAS to FreeIPA. TrueNAS had a problem
> a few versions ago where the tickets wouldn’t be renewed. It is fixed
> now. So users and groups work.
>
> The issue with TrueNAS, as I see it, is the idmapd configuration.
>
> But I think we start to be very off topic, so don’t hesitate to mail me
> directly if you want to discuss this.
>
>
> I think it can be discussed here, no problem.
>
>
> Thank you, I really appreciate this, since this is a thing I’ve been
> working on for quite sometime, so it is really nice to have other eyes on
> it.
>
> My understanding is that TrueNAS Scale uses Debian as its base. It also
> uses Samba components for both client (users/groups identities)
> integration and server (SMB shares) integration. For SMB-related
> configuration one can have a pretty decent setup with Samba-driven
> identity management, so you can define idmap ranges, plugins, etc.
>
> For NFS case, I don't see them defining any idmapd config. If winbindd
> is in use already and those users/groups are provided through nsswitch,
> then default idmapd.conf configuration should work just fine because
> it'll do UID <-> kerberos principal name translation using nsswitch.
>
>
> One of my pproblems is that I have a realm which is IPA.LOCAL. But my
> machines are machine.local. I believe that in such situations I need to
> define the Local-Realms attribute of the idmapd.conf, but that isn’t
> possible on the gui. So what happens is that when I change that on the
> /etc/idmapd.conf of TrueNAS, the permissions seem to be fine, but I still
> can’t access the folder. And after a few minutes, the idmapd.conf of
> TrueNAS gets overwritten and my permissions get messes up again, and then
> the folders are owned by nobody:nobody.
>
> But even when the permissions are right, I still can’t access the folder.
> I think it might be the ACL on 

[Freeipa-users] Re: sftp HBAC

[Kevin Vasko via FreeIPA-users]

Rob, do you by chance maybe have sshd and sftp in your "Via Services"
permissions? If I have the sshd service enabled in my "Via services" then
"sftp" works for me as well, but it's still under the hood authenticating
with sshd even though I am trying to connect with the "sftp" command.
"pam_sss" in the logs show it's using sshd, even though I have
/etc/pam.d/sshd copied over in /etc/pam.d/sftp. I think this might have
something to do with "sftp" is actually using "sshd" to do the auth?

May 16 14:59:33 exampleserver sshd[65411]: pam_sss(sshd:auth):
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=192.168.0.127 user=exampleserver
May 16 14:59:34 exampleserver sshd[65411]: pam_sss(sshd:account): Access
denied for user testuser: 6 (Permission denied)



On Tue, May 16, 2023 at 4:06 PM Rob Crittenden  wrote:

> Kevin Vasko wrote:
> > Thanks Rob.
> >
> > ipa hbactest --user testaccount --host testsystem.example.com
> > --service sftp
> > 
> > Access granted: True
> >
> > ipa hbactest --user testaccount --host testsystem.example.com
> > --service sshd
> > 
> > Access granted: False
> >
> > So the HBAC works from FreeIPA...however when I actually put rubber to
> > the road
> >
> > "sftp testacco...@testsystem.example.com"
> > Password:
> > Connection closed by UNKNOWN port 65535
> > Connection closed.
> >
> > On the server it is denying it because it seems to be using sshd like
> > Ahti Seier mentioned.
>
> You'd have to enable debugging in SSSD to see what is happening. I did
> the same and copied the pam sshd to sftp and it just worked for me,
> assuming I didn't screw something up.
>
> rob
>
> >
> >
> >
> > On Tue, May 16, 2023 at 12:56 PM Rob Crittenden  > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Kevin Vasko via FreeIPA-users wrote:
> > > Try to make this simple.
> > >
> > > Have a HBAC, have the "Who" set to a user, have the "Accessing"
> > set to a
> > > server.
> > >
> > > Have the "Via Service" set to "sshd". The user can ssh into the
> server
> > > no issue.
> > >
> > > I want to limit this user to only being able to sftp into this
> server
> > > (no direct ssh).
> > >
> > > If I swap the "Via Service" from the sshd service to sftp that
> user is
> > > now denied. They cannot access the server via sftp or ssh. I would
> > > expect it to deny ssh access but allow sftp.
> > >
> > > I did copy "cp /etc/pam.d/sshd /etc/pam.d/sftp" as I saw it
> mentioned
> > > here
> > >
> >
> https://freeipa-users.redhat.narkive.com/tFQFZmNu/hbac-service-allowed-despite-not-listed
> > > but that didn't seem to work.
> > >
> > > Can you point me to the instructions on how to make the HBAC work
> > with a
> > > particular service (e.g. sftp)?
> >
> > I just tested this and it works fine for me. I had to create an
> > allow_sshd HBAC rule which granted sshd access after I disabled the
> > allow_all rule.
> >
> > You can test your rules with:
> > ipa hbactest --user admin --host replica.example.test --service sshd
> >
> > and
> >
> > ipa hbactest --user admin --host replica.example.test --service sftp
> >
> > And replace user with whatever user can only access via sftp. It
> should
> > fail for sshd.
> >
> > It would help to see the output of these hbactest runs.
> >
> > rob
> >
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: sftp HBAC

[Kevin Vasko via FreeIPA-users]

Thanks Rob.

ipa hbactest --user testaccount --host testsystem.example.com --service sftp

Access granted: True

ipa hbactest --user testaccount --host testsystem.example.com --service sshd

Access granted: False

So the HBAC works from FreeIPA...however when I actually put rubber to the
road

"sftp testacco...@testsystem.example.com"
Password:
Connection closed by UNKNOWN port 65535
Connection closed.

On the server it is denying it because it seems to be using sshd like Ahti
Seier mentioned.



On Tue, May 16, 2023 at 12:56 PM Rob Crittenden  wrote:

> Kevin Vasko via FreeIPA-users wrote:
> > Try to make this simple.
> >
> > Have a HBAC, have the "Who" set to a user, have the "Accessing" set to a
> > server.
> >
> > Have the "Via Service" set to "sshd". The user can ssh into the server
> > no issue.
> >
> > I want to limit this user to only being able to sftp into this server
> > (no direct ssh).
> >
> > If I swap the "Via Service" from the sshd service to sftp that user is
> > now denied. They cannot access the server via sftp or ssh. I would
> > expect it to deny ssh access but allow sftp.
> >
> > I did copy "cp /etc/pam.d/sshd /etc/pam.d/sftp" as I saw it mentioned
> > here
> >
> https://freeipa-users.redhat.narkive.com/tFQFZmNu/hbac-service-allowed-despite-not-listed
> > but that didn't seem to work.
> >
> > Can you point me to the instructions on how to make the HBAC work with a
> > particular service (e.g. sftp)?
>
> I just tested this and it works fine for me. I had to create an
> allow_sshd HBAC rule which granted sshd access after I disabled the
> allow_all rule.
>
> You can test your rules with:
> ipa hbactest --user admin --host replica.example.test --service sshd
>
> and
>
> ipa hbactest --user admin --host replica.example.test --service sftp
>
> And replace user with whatever user can only access via sftp. It should
> fail for sshd.
>
> It would help to see the output of these hbactest runs.
>
> rob
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] sftp HBAC

[Kevin Vasko via FreeIPA-users]

Try to make this simple.

Have a HBAC, have the "Who" set to a user, have the "Accessing" set to a
server.

Have the "Via Service" set to "sshd". The user can ssh into the server no
issue.

I want to limit this user to only being able to sftp into this server (no
direct ssh).

If I swap the "Via Service" from the sshd service to sftp that user is now
denied. They cannot access the server via sftp or ssh. I would expect it to
deny ssh access but allow sftp.

I did copy "cp /etc/pam.d/sshd /etc/pam.d/sftp" as I saw it mentioned here
https://freeipa-users.redhat.narkive.com/tFQFZmNu/hbac-service-allowed-despite-not-listed
but that didn't seem to work.

Can you point me to the instructions on how to make the HBAC work with a
particular service (e.g. sftp)?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Trouble with resetting caches

[Kevin Vasko via FreeIPA-users]

Thanks. That is actually one of the other instances I had trouble with a
very similar type of experience. I felt I was constantly resetting
gssproxy, rpc-gssd services but it would never automatically pick up the
keytab. Left for the day and the very next day ran kinit  to pick up where
I left off and it had picked up they keytab and was showing it expires in
like the year 2999.

Granted half the time I don't even know how to begin to "reproduce" the
problem because it's so sporadic. I just constantly tweak, try to reset and
start over, and eventually it ends up working. I never find the "root
cause", it just magically starts working and it works until I have to
update something and then rinse and repeat. Prime example: I dread touching
our EMC Unity system with updates because without fail it always breaks the
kerberos authentication, but we had to update it for patches this past
week. We haven't touched this thing in 6+ months and it was working
properly before the update. Literally no configuration to the LDAP/Kerberos
settings. We simply uploaded the new updated OS and applied its patch. Sure
enough after the reboot all of the Kerberos stuff is failing saying it
can't reach the LDAP servers. Looking at the logs shows

```
1681140357: LDAP: 6: LdapService::connect: Connection to Ldap server
X.X.X.X SUCCEEDED IP[0/1]=X.X.X.X port=389
1681140357: LDAP: 3: LdapGssAuthenticator::evaluate: gss_unwrap failed -
GSS-API major error: A token had an invalid signature
1681140357: LDAP: 3: LdapGssAuthenticator::evaluate: gss_unwrap failed -
GSS-API minor error: No error
```
I changed it from Kerberos authentication to "Simple" rather than Kerberos
using a DN e.g. (uid=testuser,cn=users,cn=accounts,dc=example,dc=com). On
Friday it kept failing on my client, with "mount.nfs4: access denied by
server", (wouldn't even mount). Randomly tried it on a different client not
changing a thing and that client mounted it successfully. Left on Friday,
came back on Monday tried the mount and sure enough my client worked (I was
kdestroying on my client, albeit wasn't restarting gssproxy or rpc-gssd but
had restarted the machine that day after I changed it to Simple). Literally
could see the last command I ran on Friday was the "mount" command and it
failed, hit up on command prompt and ran it again, and it succeeded.

Most of the clients are Ubuntu, so I'm not sure if this has anything to do
with their packages versus RH based distros and how they interoperate.

If kdestroy, gssproxy, rpc-gssd, sssd indeed are the _only_ things caching
anything and a restart of those services should refresh those caches, the
next time I set one of these systems up, I'm going to document what I can.
I always dread making any changes to kerberos because of how temperamental
it is. Are there any other services I should be looking at
restarting/resetting when dealing with this topic?

On Mon, Apr 10, 2023 at 11:08 AM Rob Crittenden  wrote:

> Kevin Vasko via FreeIPA-users wrote:
> > Hello,
> >
> > Does anyone have any tips for completely refreshing (forcing cleaning)
> > all kerberos tickets on a client from FreeIPA?
> >
> > I assumed "$ kdestroy -A" should do it, but it certainly doesn't
> > completely clear all caches.
> >
> > What I'm having trouble with is some NFS/NAS servers using kerberos.
> > I'll set up a new NFS server with Kerberos, the server will have their
> > appropriate keytab and services created.
> >
> > I'll make sure and clear my local cache on my client with "$ kdestroy
> > -A", and then connect to the NFS server. If for some reason I have
> > something misconfigured (e.g. time is off) I'll obviously get a "stale
> > file handle" or "mount.nfs4: access denied by server". At that point
> > I'll correct the issue on the server/client. However, I'll continue
> > getting the error even though I destroy the cache. I _know_ its a cache
> > issue _somewhere_ because it will randomly start working (e.g. it will
> > be failing, leave for the day and next morning it will mount no problem)
> > OR I'll try it on a different client and it will mount successfully. It
> > seems so sporadic. I've even been in the situation where I've
> > purposefully removed keytabs, LDAP login access and reset the cache on
> > the client on systems the and NFS mount has still worked. It will
> > continue to work when it shouldn't as I've removed keytab or
> > authentications so obviously something is cached.
> >
> > Is there a foolproof list of things I need to do to reset the cache(es)?
> > kdestroy, services on client and server? Is there a potential force 15
> > min TTL or something somewhere I'm missing?
>
> It is probably gssproxy holding the credentials. See
> htt

[Freeipa-users] Trouble with resetting caches

[Kevin Vasko via FreeIPA-users]

Hello,

Does anyone have any tips for completely refreshing (forcing cleaning) all
kerberos tickets on a client from FreeIPA?

I assumed "$ kdestroy -A" should do it, but it certainly doesn't completely
clear all caches.

What I'm having trouble with is some NFS/NAS servers using kerberos. I'll
set up a new NFS server with Kerberos, the server will have their
appropriate keytab and services created.

I'll make sure and clear my local cache on my client with "$ kdestroy -A",
and then connect to the NFS server. If for some reason I have something
misconfigured (e.g. time is off) I'll obviously get a "stale file handle"
or "mount.nfs4: access denied by server". At that point I'll correct the
issue on the server/client. However, I'll continue getting the error even
though I destroy the cache. I _know_ its a cache issue _somewhere_ because
it will randomly start working (e.g. it will be failing, leave for the day
and next morning it will mount no problem) OR I'll try it on a different
client and it will mount successfully. It seems so sporadic. I've even been
in the situation where I've purposefully removed keytabs, LDAP login access
and reset the cache on the client on systems the and NFS mount has still
worked. It will continue to work when it shouldn't as I've removed keytab
or authentications so obviously something is cached.

Is there a foolproof list of things I need to do to reset the cache(es)?
kdestroy, services on client and server? Is there a potential force 15 min
TTL or something somewhere I'm missing?

Thanks,

-Kevin
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check

[Kevin Vasko via FreeIPA-users]

Appreciate the response.

Unfortunately, I’ve got the hand i’ve been deal with. Our machines normally 
have 1-2 but if someone hardcodes a single DNS it’s probably going to the main 
server. The systems using DHCP would be fine…but for the ones that aren’t it 
will just all break. 

No matter, to me this seems all very complicated. In my eyes it would be way 
more fragile than a single dot version upgrade. Is FreeIPA that sensitive going 
from 4.5 to 4.6? 

Is FreeIPA really this fragile? I’ve honestly been nervous with this mess 
because I feel if something fails, I’ll never get it back running properly as 
it’s less like a “ok let’s reset and start over”. 

Honestly what I feel like my quickest and best approach is to snapshot all of 
the IPA systems, pick one to run yum update on and see what happens. If it 
breaks, simply revert all of them back. Would this be a really bad idea?

-Kevin

> On Feb 8, 2023, at 8:59 PM, Jernej Jakob  wrote:
> 
> I forgot one more option. Since the first server is older than the
> other 2, you could not upgrade it but just shut it down. Follow the
> procedures: promote one of the two newer servers to CA renewal master,
> follow steps to decomission/remove the server from the domain, remove
> DNS SRV and A/ records. Remove RUVs pointing to it. Then change the
> IP of that server's NIC to something else, and assign its IP(s) to one
> of the other 2 servers (add alias/es). So requests for DNS will then
> hit one of the remaining servers. Someone more knowledgeable can
> confirm if this is a good option - I personally did this and it worked
> (temporarily until I can change the DNS settings on all machines with
> static config).
> 
>> On Thu, 9 Feb 2023 03:44:35 +0100
>> Jernej Jakob via FreeIPA-users 
>> wrote:
>> 
>> On Wed, 8 Feb 2023 09:53:35 -0600
>> Kevin Vasko via FreeIPA-users 
>> wrote:
>> 
>>> Thanks Rafael.
>>> 
>>> I was hoping to do it in place if at all possible because where things get
>>> complicated is the 4.5.4 server is also the internal DNS server that
>>> everyone utilizes (we have multiple but people just use the 1 mainly). It
>>> really was their "main" server. I added the other two replicas a few years
>>> ago to make sure we had something. They contacted me and wanted help to
>>> upgrade everything so here I am. Making any modifications to it will
>>> probably make everything go heywire (or at least break DNS for everyone).
>>> That is unless I get it back immediately by
>>> 
>>> 1. adding a 4th server
>>> 2. promoting the 4th server to master
>>> 3. decommission the 4.5.4 server
>>> 4. reassign the 4th server the same IP as the old 4.5.4 server?
>>> 5. upgrade rest of servers
>>> 
>>> Any thoughts? recommendations?
>>> 
>> 
>> IMO they really should be using at least 2, if not all 3, of those as
>> DNS servers. Then even if the primary is down, they should fail over to
>> the secondary or tertiary (with the only symptom being slow resolving,
>> so users will notice it, but will still be able to work).
>> I've only noticed one thing in my network not failing over to secondary
>> as it should, docker. If primary from resolv.conf is down, it will fail
>> over to Google's 8.8.8.8 instead of your secondary.
>> The other possibility is that you configure your firewall to DNAT
>> all requests on UDP/TCP port 53 to the other, working server. But this
>> will only work for requests coming from other networks which pass
>> through your router. It's why I use lots of VLANs, I have all the IPA
>> servers in their own VLAN so I could do this. But if you have other
>> machines in the same network they won't be passing through the router
>> so that won't be possible.
>> The third possibility is that you set up DNAT with masquerading on the
>> IPA server you will be upgrading, to translate packets to the other
>> server, masquerade to make the reply packets go back through the same
>> path (otherwise they may be dropped due to source IP mismatch). This
>> will work for all requests including those not passing the router, but
>> will only work while the OS is booted. So you can shut down IPA and it
>> will work but if you need to restart the OS it will also go down.
>> 
>>> 
>>>> On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman  wrote:
>>> 
>>>> 
>>>> 
>>>> On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
>>>> freeipa-users@lists.fedorahosted.org> wrote:
>>>>> 
>>>>> We have a set of 3x freeIPA servers that have outdate

[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check

[Kevin Vasko via FreeIPA-users]

Thanks Rafael.

I was hoping to do it in place if at all possible because where things get
complicated is the 4.5.4 server is also the internal DNS server that
everyone utilizes (we have multiple but people just use the 1 mainly). It
really was their "main" server. I added the other two replicas a few years
ago to make sure we had something. They contacted me and wanted help to
upgrade everything so here I am. Making any modifications to it will
probably make everything go heywire (or at least break DNS for everyone).
That is unless I get it back immediately by

1. adding a 4th server
2. promoting the 4th server to master
3. decommission the 4.5.4 server
4. reassign the 4th server the same IP as the old 4.5.4 server?
5. upgrade rest of servers

Any thoughts? recommendations?


On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman  wrote:

>
>
> On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> >
> > We have a set of 3x freeIPA servers that have outdated (everything) in a
> development/test environment that need to be updated.
> >
> > It seems that 4.6.8-5.el7.centos.12 is the latest version available on
> CentOS 7?
> >
> > We are at on the 3 servers:
> > 4.5.4-10.el7.centos.4.4
> > 4.6.4-10-el7.centos.6
> > 4.6.4-10-el7.centos.6
> >
> > For the two 4.6.4 installs, that seems relatively simple upgrade as we
> would only be going to a different dot release and a simple "yum update
> ipa-server" should handle this? Is there any advisement for/against doing a
> full "yum update" on the entire system to get everything updated?
> >
> > For the 4.5.4 system, is there much of a concern going straight from
> 4.5.4 to 4.6.8 straight? I assume the concern would be jumping major
> versions and going from say 4.5 to 4.9?
> >
> > My current plan is to stop at CentOS 7.9 and latest FreeIPA 4.6 release
> on CentOS 7.9. But for my own knowledge if I was going to 4.10 wouldn't the
> recommendation path to upgrade to 4.10, to install CentOS Stream 9 on a new
> server, enroll it, make 4.10 the master and then remove the CentOS 7
> instances?
> >
>
> Assuming you can't have a 4th server, Is it possible for you to have only
> 2 replicas for some time? If so, you can remove the 4.5.4 server, fully
> (cleanly?) upgrade it, add it back, set it as CA master, and repeat the
> procedure with the other servers.
>
> As you are upgrading the whole OS, this would be more in line with the
> current recommendation (see
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating
> ).
>
> Rafael
>
> > -Kevin
> >
> >
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> Rafael Guterres Jeffman
> Senior Software Engineer
> FreeIPA - Red Hat
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Upgrade outdated FreeIPA sanity check

[Kevin Vasko via FreeIPA-users]

We have a set of 3x freeIPA servers that have outdated (everything) in a
development/test environment that need to be updated.

It seems that 4.6.8-5.el7.centos.12 is the latest version available on
CentOS 7?

We are at on the 3 servers:
4.5.4-10.el7.centos.4.4
4.6.4-10-el7.centos.6
4.6.4-10-el7.centos.6

For the two 4.6.4 installs, that seems relatively simple upgrade as we
would only be going to a different dot release and a simple "yum update
ipa-server" should handle this? Is there any advisement for/against doing a
full "yum update" on the entire system to get everything updated?

For the 4.5.4 system, is there much of a concern going straight from 4.5.4
to 4.6.8 straight? I assume the concern would be jumping major versions and
going from say 4.5 to 4.9?

My current plan is to stop at CentOS 7.9 and latest FreeIPA 4.6 release on
CentOS 7.9. But for my own knowledge if I was going to 4.10 wouldn't the
recommendation path to upgrade to 4.10, to install CentOS Stream 9 on a new
server, enroll it, make 4.10 the master and then remove the CentOS 7
instances?

-Kevin
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: password-expiration

[Kevin Vasko via FreeIPA-users]

I’m in a similar situation and need to upgrade.

These docs are what I found 
https://www.freeipa.org/page/Upgrade#FreeIPA_4.2.0_or_newer and it seems to 
imply to simply run a yum update freeipa-server to go to the latest version. Is 
there some other documentation I should be following?

-Kevin

> On Feb 7, 2023, at 10:51 AM, Rob Crittenden via FreeIPA-users 
>  wrote:
> 
> When using --setattr you have to use the LDAP attribute name. So in this
> case givenname.
> 
> 4.5.4 is getting along to 6 years old now. In general we strongly
> encourage you to upgrade to a supported release, one release at a time
> (there is no going from 4.5 to 4.10 directly).
> 
> rob
> 
> None via FreeIPA-users wrote:
>> 
>> 
>> Hi Florence,
>> 
>> I've tried the --setattr option with 'first', 
>> 
>> 
>> ipa user-mod user1 --setattr first=phil
>> 
>> ... but to no avail 
>> 
>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 
>> 'first' attribute of 
>> entry 'uid=...'.
>> 
>> 
>> 
>> - Mail original -
>> De: "Florence Blanc-Renaud via FreeIPA-users" 
>> 
>> À: phi...@free.fr
>> Cc: freeipa-users@lists.fedorahosted.org, "Florence Blanc-Renaud" 
>> 
>> Envoyé: Mardi 7 Février 2023 17:37:19
>> Objet: [Freeipa-users] Re: password-expiration
>> 
>> 
>> 
>> 
>> 
>> Hi, 
>> 
>> 
>> 
>> On Tue, Feb 7, 2023 at 5:23 PM < phi...@free.fr > wrote: 
>> 
>> 
>> Hi Florence, 
>> alas, same issue 
>> 
>> ipa: error: no such option: --password-expiration 
>> 
>> 
>> 
>> Ok, the functionality was added in 4.6.0 (see Release notes ) so you need to 
>> use directly ipa user-mod LOGIN --setattr krbpasswordexpiration =VALUE 
>> flo 
>> 
>> 
>> 
>> 
>> 
>> 
>> - Mail original - 
>> De: "Florence Blanc-Renaud" < f...@redhat.com > 
>> À: phi...@free.fr 
>> Cc: freeipa-users@lists.fedorahosted.org 
>> Envoyé: Mardi 7 Février 2023 17:12:32 
>> Objet: Re: [Freeipa-users] password-expiration 
>> 
>> 
>> 
>> 
>> Hi, 
>> 
>> 
>> 
>> On Tue, Feb 7, 2023 at 4:49 PM < phi...@free.fr > wrote: 
>> 
>> 
>> Hi Florence, 
>> unfortunately, 
>> 
>> ipa user-mod user1 --krbpasswordexpiration='2024-06-28 07:49:37Z' 
>> Usage: ipa [global-options] user-mod LOGIN [options] 
>> 
>> ipa: error: no such option: --krbpasswordexpiration 
>> 
>> 
>> My bad, I copied the attribute name instead of the CLI option name. Can you 
>> try with 
>> ipa user-mod LOGIN --password-expiration =DATETIME 
>> 
>> 
>> Note: if you type ipa user-mod --help you can see all the available options. 
>> flo 
>> 
>> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Local account override IPA account

[Kevin Vasko via FreeIPA-users]

I know this is probably stupid but we have a server with a local account (let’s 
call this local user “user1”). This server and its install predated our IPA 
install. This local user also has sudoers exception for this account for a 
“NOPASSWD” locally on this machine and this machine alone. 

After some period of time (it’s been like this for years), we added this 
“user1” account to FreeIPA so we could use it on other select machine. We kept 
using the local account as if nothing changed.

This server with the local “user1” account was on Ubuntu 18.04 and with this 
set up was working fine. We upgraded it to Ubuntu 20.04 and it broke the 
sudoers “NOPASSWD”. This local account can no longer execute commands without a 
password as it seems sssd is overriding the “local account” and going back to 
IPA and asking for its authentication (user1 on this box is local and has a uid 
of 1000, the freeipa user1 had the random freeIPA generated 123456789 UID). 

In my nsswitch.conf 

For passwd, group, sudoers all of them have “files” listed first which should 
instruct sssd to prioritize local account information first, correct? 

If I remove “sss” from the nsswitch sudoers line it works as expected. 

Is this a regression in sssd or something else Im missing?


-Kevin
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Options for remote home directories

[Kevin Vasko via FreeIPA-users]

Trying to find the best option for me for better “shared” “/home” directories.

I ideally would like to give everyone a network based /home directory so I 
could quota the folders so people would quit filling up every severs /home 
directory. 

We have two major use cases, the first isn’t much of a problem, but combined 
with the second it makes a problem. 

* We have servers that people login to with their LDAP that are always 
connected to our NFS server. 

* We also have laptops that users login with their LDAP account and connect to 
the network via VPN.

I realize I can force everyone’s home directory to like /nfshome/ in 
freeIPA, but the problem with this is if they are remote on the laptop it 
causes all kinds of issues when they aren’t on the VPN.

What are my options for handling this? Should I just quota everyone on the 
severs and tell everyone to use /nfshome/ and then leave the laptops 
alone? 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] NFS Mount idmap on ubuntu

[Kevin Vasko via FreeIPA-users]

I think something recently changed on Ubuntu 20.04 where I’m now having to put 

Domain = my.domain.com

In /etc/idmapd.conf or run ipa-client-automount to have that do it for me.

No matter, my issue is I effectively have to reboot after making the change. 

I can restart sssd, all the rpc* services I can find and no matter what i 
restart when I “ls -l /mnt/nfs_share”. Everything is still owned by 
nobody:nogroup.

I have unmounted and restarted all the services I can find and same issue.

If I reboot the whole server and 

Domain = my.domain.com

Is in the the conf file, it works.

No matter what services I restart in the client nothing makes it work until I 
reboot. I’ve tested it by removing it, get the nobody:nogroup and then putting 
it in the config, restart all the services and nothing fixes it.

Reboot the machine and magically it’s back working.

What services am I missing that I need to restart for force this thing to pick 
up user and groups on the NFS share? 

sssd
rpc-gssd 
rpcbind 


-Kevin___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] FreeIPA with containers

[Kevin Vasko via FreeIPA-users]

Hello,
 
We have our NFS servers kerberized which requires a ticket to be able to access 
the NFS share. We also have a GPU cluster where people get to launch docker 
containers to complete work. Unfortunately, within the container users can’t 
access the NFS share even though its mapped on the host machine and in the 
container because they don’t have a ticket within the container.
 
So what are my options to deal with this? Would building a container and when 
it starts up, automatically enroll itself into FreeIPA be the best solution? As 
a test I tried to enroll the container in one of our test containers and 
freeipa-client-install complained that pid 1 wasn’t being ran by systemd, not 
quite sure how to get around that. However even if this was accomplished could 
enrolling 100s or 1000s of containers cause an issue for freeIPA?Most of these 
would be fairly short lived (few days to weeks). At that point I would need to 
go manually cleanup all of the enrolled machines.
 
The other and less optimal solution would be to use a non kerberized NFS share, 
pass through the uid/gid from the host, but with this solution users would know 
their own UID/GID in the container but wouldn’t know who owns what in the 
container because they would have nothing tell them in the container what 
UID/GID is associated with what account so it might get confusing.
 
I’m really just looking for any suggestions on what other people have done. I’m 
not even sure if what I’m doing is the right approach at all and I should be 
doing something totally different. Are there any other solutions/suggestions 
that people have used to operate with FreeIPA along with docker containers?

-Kevin___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] permanent service account keys for kerberos NFS share

[Kevin Vasko via FreeIPA-users]

Hello,

We have an application that does some data processing on our NFS server. Users 
typically just ssh into a box which then has a kerberos key generated for them, 
which allows them access the NFS share and run the script.

We are wanting to set this up in a more automated fashion. Such as running the 
script in the background as a service. However, after a few days the kerberos 
keys become invalid killing access to the NFS share and the data.

Is there a way to generate some account/keys that will have permanent access 
for service level stuff like this? 

-Kevin
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Approach to allowing users access to NFS with kerberos through containers

[Kevin Vasko via FreeIPA-users]

Our users on their local machines (which are enrolled into our domain/realm) 
access (mount read/write) our NFS shares as they need with their LDAP accounts. 

We are wanting to allow users to use docker containers to mount/access these 
same mount/NFS Servers. These containers are short lived so enrolling them into 
the realm wouldn’t be feasible. Is there a short circuit to allow users to have 
access to the Kerberos tickets so they can mount the NFS stores? Or is this a 
bad idea? 

-Kevin
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Ubuntu client: Kerberos works, authentication does not

[Kevin Vasko via FreeIPA-users]

Is the clock off? NTP working correctly? 

-Kevin

> On Mar 7, 2020, at 12:55 PM, Nicholas DeMarco  wrote:
> 
> 
> Good question. Yes. The user is in the admin group and has access to other 
> newly joined machines.
> 
>> On Sat, Mar 7, 2020, 1:39 PM Kevin Vasko  wrote:
>> Does the user have access to the machine?
>> 
>> -Kevin
>> 
>> > On Mar 7, 2020, at 11:33 AM, Nicholas DeMarco via FreeIPA-users 
>> >  wrote:
>> > 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Ubuntu client: Kerberos works, authentication does not

[Kevin Vasko via FreeIPA-users]

Does the user have access to the machine?

-Kevin

> On Mar 7, 2020, at 11:33 AM, Nicholas DeMarco via FreeIPA-users 
>  wrote:
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: dhcp dynamic update

[Kevin Vasko via FreeIPA-users]

I’m interested in hearing others responses as well on this. 

Is there anything in particular I would need to do to make sure I can get 
things back into a “working” state? 

-Kevin

> On Feb 24, 2020, at 12:10 PM, Andrew Meyer via FreeIPA-users 
>  wrote:
> 
> Hello,
> I was trying to search the mailing list before emailing about this but has 
> anyone set this up 
> https://archyslife.blogspot.com/2019/01/freeipa-integrating-your-dhcpd-dynamic.html
>  OR https://www.freeipa.org/page/Howto/ISC_DHCPd_and_Dynamic_DNS_update in 
> their environment?  
> 
> In the past I ran into issues when making changes to /etc/named.conf so 
> before I go doing this I wanted to make sure others had tried this out.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Help in understanding multiple KVNO versions in keytab file

[Kevin Vasko via FreeIPA-users]

Hello,
 
I’m trying to understand when/how the different KVNO versions in a file should 
or shouldn’t work. We have a Dell EMC Unity box that’s giving us fits on what 
it will accept for a keytab file with different KVNO versions. I’m not sure if 
I’m misunderstanding something, or there’s a bug somewhere. 
 
So to start…
 
Create a host:
ipa host-add emc-nas-server.example.com --ip-address 10.75.37.2
 
Create a service:
ipa service-add NFS/emc-nas-server.example@example.com
 
Get a keytab file:
ipa-getkeytab -s ipaserver.example.com -p nfs/emc-nas-server.example.com -k 
/tmp/emc-nas-server.keytab –P
 
Check the keytab file:
ktutil
ktutil:  read_kt /tmp/emc-nas-server.example.com.keytab
ktutil:  list
slot KVNO Principal
  -
   11 nfs/emc-nas-server.example@example.com
   21 nfs/emc-nas-server.example@example.com
 
I upload the keytab file to the Dell Unity box. I can then mount the NFS share 
no problem with Kerberos sec=krb5
 
Now where my question comes in, if I generate a new keytab file with
 
ipa-getkeytab -s ipaserver.example.com -p nfs/emc-nas-server.example.com -k 
/tmp/emc-nas-server.keytab –P
 
Check the keytab file:
ktutil
ktutil:  read_kt /tmp/emc-nas-server.example.com.keytab
ktutil:  list
slot KVNO Principal
  -
   11 nfs/emc-nas-server.example@example.com
   21 nfs/emc-nas-server.example@example.com
   32 nfs/emc-nas-server.example@example.com
   42 nfs/emc-nas-server.example@example.com
 
So now this keytab file has version 1 and version 2 in the keytab file. If I 
upload this file to the Dell Unity box and try to mount the NFS share that’s 
being validated via Kerberos it fails to mount. I validated that my NFS client 
is now sending kvno 2 with tcpdump. 
 
Since the Unity box has the new keytab file with 2 versions, shouldn’t the 
Unity box be checking against all of the versions of the keytab file or at 
least the latest (KVNO 2) allowing the mount to work? It seems that the Unity 
box is only checking against 1 KVNO version and failing. Since it’s the same 
keytab file shouldn’t this work or am I misunderstanding something?
 
Thanks,

-Kevin___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Easiest path to provide access to shares to Windows and Mac systems

[Kevin Vasko via FreeIPA-users]

So I feel we have a decent process for users on Linux (Ubuntu/CentOS)
to access NFS shares, however there is rumbling of people wanting to
use their Mac and Windows boxes to access the data shares.

The tricky part of this is we won't be able to enroll the Windows or
Mac systems into FreeIPA.

So is there a "simple" way to allow users on Mac and Windows that
can't be enrolled into the FreeIPA domain to access kerberized NFS
shares? I think this is going to be difficult in general to windows
and might have to swap to SMB?

For example, is there a way to download a SMB+Kerberos clients, grab
the keys from IPA and allow users to manually authenticate with kinit
and be able to access the NFS or a SMB share?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ca-certificate file not being parses correctly on Ubuntu with p11-kit-trust.so due to data inserted by FreeIPA Client install

[Kevin Vasko via FreeIPA-users]

Thanks.

I posted the bug report.

https://pagure.io/freeipa/issue/8106

-Kevin

> On Oct 28, 2019, at 9:24 AM, Alexander Bokovoy  wrote:
> 
> On ma, 28 loka 2019, Kevin Vasko via FreeIPA-users wrote:
>> 
>> 
>> Mainly looking for input on where to file a bug I think I found in
>> p11-kit-trust.so but potentially caused by the FreeIPA client install
>> process on Ubuntu.
>> 
>> I have been trying to figure out a way of getting Ubuntu to load the
>> system wide certs like CentOS/Fedora does. Alexander helped me
>> troubleshoot my issues on CentOS/Fedora and those system work out of
>> the box (after I fixed my mistake
>> https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg07903.html).
>> However, on Ubuntu you have to take it a slight step further by using
>> the p11-kit-trust.so manually it seems.
>> 
>> I found this link
>> https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285
>> that has a bug report that states you can just symlink the
>> p11-kit-trust.so to the /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
>> https://superuser.com/a/1312419/411058and it would “just work”.
>> 
>> Unfortunately, I was having trouble figuring out how to get it to work.
>> I spent a couple days or so troubleshooting and trying to figure out
>> why it wasn’t working. Once I would do the symlink to the
>> p11-kit-trust.so, no certificates _at all_ would load in any browser
>> (chome/firefox). If I removed the symlink and put the libnssckbi.so
>> file the browsers would go back to loading the static system wide certs
>> (obviously the certs I included wouldn’t work). Eventually I ran across
>> this documentation from p11-kit to find out how to debug p11-kit.
>> https://p11-glue.github.io/p11-glue/trust-module.html
>> 
>> I ran
>> 
>> P11_KIT_DEBUG=all firefox
>> 
>> With that log output I finally found something to point me in the
>> correct direction. Based on this log it seems like p11-kit is having
>> issues parsing the ca-certificates.crt file.
>> 
>> $ P11_KIT_DEBUG=all firefox
>> (p11-kit:10001) p11_library_init_impl: initializing library
>> (p11-kit:10001) uninit_common: uninitializing library
>> (p11-kit:10057) p11_library_init_impl: initializing library
>> (p11-kit:10057) uninit_common: uninitializing library
>> (p11-kit:10001) p11_library_init_impl: initializing library
>> (p11-kit:10001) sys_C_Initialize: in
>> (p11-kit:10001) sys_C_Initialize: doing initialization
>> (p11-kit:10001) create_tokens_inlock: using paths: 
>> /etc/ssl/certs/ca-certificates.crt
>> (p11-kit:10001) p11_token_new: token: System Trust: 
>> /etc/ssl/certs/ca-certificates.crt
>> (p11-kit:10001) sys_C_Initialize: out: 0x0
>> (p11-kit:10001) sys_C_GetInfo: in
>> (p11-kit:10001) sys_C_GetInfo: out: 0x0
>> (p11-kit:10001) sys_C_GetSlotList: in
>> (p11-kit:10001) sys_C_GetSlotList: out: 0x0
>> (p11-kit:10001) sys_C_GetSlotList: in
>> (p11-kit:10001) sys_C_GetSlotList: out: 0x0
>> (p11-kit:10001) sys_C_GetSlotInfo: in
>> (p11-kit:10001) sys_C_GetSlotInfo: out: 0x0
>> (p11-kit:10001) sys_C_GetTokenInfo: in
>> (p11-kit:10001) sys_C_GetTokenInfo: out: 0x0
>> (p11-kit:10001) sys_C_GetMechanismList: in
>> (p11-kit:10001) sys_C_GetMechanismList: out: 0x0
>> (p11-kit:10001) sys_C_GetMechanismList: in
>> (p11-kit:10001) sys_C_GetMechanismList: out: 0x0
>> (p11-kit:10001) sys_C_OpenSession: in
>> (p11-kit:10001) sys_C_OpenSession: session: 17
>> (p11-kit:10001) sys_C_OpenSession: out: 0x0
>> (p11-kit:10001) sys_C_FindObjectsInit: in: 17, (1) [ { CKA_CLASS = 
>> CKO_NSS_BUILTIN_ROOT_LIST } ]
>> (p11-kit:10001) message: ca-certificates.crt: BEGIN ...: pem block before 
>> p11-kit section header
>> (p11-kit:10001) loader_load_file: failed to parse: 
>> /etc/ssl/certs/ca-certificates.crt
>> (p11-kit:10001) sys_C_FindObjectsInit: out: 0x0
>> (p11-kit:10001) sys_C_FindObjects: in: 17, 1
>> (p11-kit:10001) sys_C_FindObjects: out: 0x11, 1
>> (p11-kit:10001) sys_C_FindObjectsFinal: in
>> (p11-kit:10001) sys_C_FindObjectsFinal: out: 0x0
>> 
>> 
>> I looked at the ca-certificates.crt file
>> 
>> Nothing looked abnormal until I saw this…
>> 
>> previous part of ca-certificates.crt
>> 
>> 
>> # This file was created by IPA. Do not edit.
>> 
>> [p11-kit-object-v1]
>> class: certificate
>> certificate-type: x-509
>> certificate-category: authority
>> label: 
>> subject: ": "
>> issuer: ": "
>> serial-number: “"
>

[Freeipa-users] ca-certificate file not being parses correctly on Ubuntu with p11-kit-trust.so due to data inserted by FreeIPA Client install

[Kevin Vasko via FreeIPA-users]

Mainly looking for input on where to file a bug I think I found in 
p11-kit-trust.so but potentially caused by the FreeIPA client install process 
on Ubuntu.
 
I have been trying to figure out a way of getting Ubuntu to load the system 
wide certs like CentOS/Fedora does. Alexander helped me troubleshoot my issues 
on CentOS/Fedora and those system work out of the box (after I fixed my mistake 
https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg07903.html).
 However, on Ubuntu you have to take it a slight step further by using the 
p11-kit-trust.so manually it seems.
 
I found this link 
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285 that has 
a bug report that states you can just symlink the p11-kit-trust.so to the 
/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so 
https://superuser.com/a/1312419/411058and it would “just work”.
 
Unfortunately, I was having trouble figuring out how to get it to work. I spent 
a couple days or so troubleshooting and trying to figure out why it wasn’t 
working. Once I would do the symlink to the p11-kit-trust.so, no certificates 
_at all_ would load in any browser (chome/firefox). If I removed the symlink 
and put the libnssckbi.so file the browsers would go back to loading the static 
system wide certs (obviously the certs I included wouldn’t work). Eventually I 
ran across this documentation from p11-kit to find out how to debug p11-kit. 
https://p11-glue.github.io/p11-glue/trust-module.html
 
I ran 
 
P11_KIT_DEBUG=all firefox 
 
With that log output I finally found something to point me in the correct 
direction. Based on this log it seems like p11-kit is having issues parsing the 
ca-certificates.crt file.
 
$ P11_KIT_DEBUG=all firefox
(p11-kit:10001) p11_library_init_impl: initializing library
(p11-kit:10001) uninit_common: uninitializing library
(p11-kit:10057) p11_library_init_impl: initializing library
(p11-kit:10057) uninit_common: uninitializing library
(p11-kit:10001) p11_library_init_impl: initializing library
(p11-kit:10001) sys_C_Initialize: in
(p11-kit:10001) sys_C_Initialize: doing initialization
(p11-kit:10001) create_tokens_inlock: using paths: 
/etc/ssl/certs/ca-certificates.crt
(p11-kit:10001) p11_token_new: token: System Trust: 
/etc/ssl/certs/ca-certificates.crt
(p11-kit:10001) sys_C_Initialize: out: 0x0
(p11-kit:10001) sys_C_GetInfo: in
(p11-kit:10001) sys_C_GetInfo: out: 0x0
(p11-kit:10001) sys_C_GetSlotList: in
(p11-kit:10001) sys_C_GetSlotList: out: 0x0
(p11-kit:10001) sys_C_GetSlotList: in
(p11-kit:10001) sys_C_GetSlotList: out: 0x0
(p11-kit:10001) sys_C_GetSlotInfo: in
(p11-kit:10001) sys_C_GetSlotInfo: out: 0x0
(p11-kit:10001) sys_C_GetTokenInfo: in
(p11-kit:10001) sys_C_GetTokenInfo: out: 0x0
(p11-kit:10001) sys_C_GetMechanismList: in
(p11-kit:10001) sys_C_GetMechanismList: out: 0x0
(p11-kit:10001) sys_C_GetMechanismList: in
(p11-kit:10001) sys_C_GetMechanismList: out: 0x0
(p11-kit:10001) sys_C_OpenSession: in
(p11-kit:10001) sys_C_OpenSession: session: 17
(p11-kit:10001) sys_C_OpenSession: out: 0x0
(p11-kit:10001) sys_C_FindObjectsInit: in: 17, (1) [ { CKA_CLASS = 
CKO_NSS_BUILTIN_ROOT_LIST } ]
(p11-kit:10001) message: ca-certificates.crt: BEGIN ...: pem block before 
p11-kit section header
(p11-kit:10001) loader_load_file: failed to parse: 
/etc/ssl/certs/ca-certificates.crt
(p11-kit:10001) sys_C_FindObjectsInit: out: 0x0
(p11-kit:10001) sys_C_FindObjects: in: 17, 1
(p11-kit:10001) sys_C_FindObjects: out: 0x11, 1
(p11-kit:10001) sys_C_FindObjectsFinal: in
(p11-kit:10001) sys_C_FindObjectsFinal: out: 0x0
 
 
I looked at the ca-certificates.crt file 
 
Nothing looked abnormal until I saw this…
 
previous part of ca-certificates.crt
 
 
# This file was created by IPA. Do not edit.
 
[p11-kit-object-v1]
class: certificate
certificate-type: x-509
certificate-category: authority
label: 
subject: ": "
issuer: ": "
serial-number: “"
x-public-key-info: ": "
trusted: true
--BEGIN CERTIFICATE--
…..
rest of ca-certificates.crt 
 
Once I removed the section above the “…BEGIN CERTIFICATE…” and after the prior 
“END CERTIFICATE“ everything started working properly. I put it back 
and things broke again.

So this indicates that p11-kit-trust.so isn’t parsing the ca-certificate.crt 
file due to the information that the FreeIPA client install put into the file.
 
I am using the latest version that comes with Ubuntu 18.04 of p11-kit-trust 
(0.23).
 
So my question is, should this be a bug report to Ubuntu’s implementation of 
the FreeIPA client install that adds the certificate information or should I 
file a bug report against the p11-kit module to have them fix the parsing issue?
 
Any thoughts/suggestions?
 
-Kevin
 ___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 

[Freeipa-users] Re: group management on freeipa clients

[Kevin Vasko via FreeIPA-users]

So. this is an interesting read thanks for that.

But just a FYI to the OP, if you are using any Ubuntu 18.04 clients (i haven’t 
tried it with Fedora/CentOS) there is an issue with not having local docker 
groups on the system.

What ends up happening is on a boot, docker services try starting up, but look 
for a local docker group when they do. If there is no docker group the service 
times out. When the machine does finally boot up, DNS resolution for some 
reason is broken. Networking works fine (e.g can ping 8.8.8.8 or any local ip). 
But without DNS resolution the machine won’t properly find the IPA server and 
won’t allow users to login. 

Docker made this service change from 16.04 to 18.04. 

Here I detailed how I determined what the issue was. I put in another ticket 
with this information but was told it wasn’t an issue with docker.

https://github.com/docker/libnetwork/issues/2335



-Kevin

> On Oct 24, 2019, at 6:18 PM, Simo Sorce via FreeIPA-users 
>  wrote:
> 
> I strongly recommend reading this article:
> https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/
> 
> And based on it, I would a) reconsider if using sudo is not a better
> idea, b) recommend, if possible, to create the docker group locally and
> add users explicitly on the specific machines.
> 
> I would fallback to a global docker group that basically gives root to
> any user on any machine with docker installed they have access to only
> as a least resort.
> 
> Simo.
> 
>> On Wed, 2019-10-23 at 19:07 +, Jason Dunham via FreeIPA-users
>> wrote:
>> Hi I'm trying to figure out the best practice for groups on my client 
>> servers.
>> I have several computation workstation hosts that have been added as freeipa 
>> clients, and several engineers who want to run docker on them
>> Members of the 'docker' group (gid=999 on some machines, for example) can 
>> run docker without needing sudo, which is what I want to roll out to all 
>> machines.  Ideally this would be managed from freeipa with LDAP groups, and 
>> so anyone in the 'engineers' group should also be a member of the 'docker' 
>> group.
>> When I create a 'docker' group on freeIPA it will have some other gid and 
>> the client sees that.
>> Should I just delete the original docker group from my hosts and let it get 
>> it from ldap, or should I go into /etc/group and change the gid to the one 
>> that matches the right ldap gid, or preferably something easier than that?
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

Well that’s the thing, I didn’t realize the service certificate was revoked as 
I thought the entire point of validating the client cert was to validate the 
entire “chain” with OCSP. 

Im using IPAs internal cert system. 

Yeah, I kept reissueing tickets when I was trying to get the post command 
script to work. I guess in the process I deleted one to many certs and didn’t 
realize it.

So if I would have ran the command on the services cert I should have seen it’s 
revoked? 

Is there a command to do exactly what FF is doing for OCSP to validate the 
cert? Or should I just manually check each cert, client and service?


Thanks again for all of the help. I think at this point I’m wrapping my head 
around it at least.

Now to go mess with Ubuntu to get Firefox to read those system certs since now 
I know CentOS 100% works...

-Kevin

> On Oct 14, 2019, at 9:50 AM, Alexander Bokovoy  wrote:
> 
> On ma, 14 loka 2019, Kevin Vasko wrote:
>> Welp, I'm an idiot and you are completely 100% correct.
>> 
>> It was indeed revoked, but the http servers certificate was revoked
>> and not the client..which is where I was focusing 100% of my
>> debugging. Which clears up a LOT of things. I originally was loading
>> the ca.crt on an Ubuntu machine a few days prior to this and it was
>> working completely fine. After a few days I was getting the
>> "SEC_ERROR_REVOKED_CERTIFICATE" when I went back to try it again.
>> 
>> However, what doesn't make sense to me is all of the commands I was
>> running to check the certs were telling me that the certs were 100%
>> okay and not revoked...
>> 
>> I ran this command which is supposedly supposed to tell me if my cert
>> is okay with OCSP
>> 
>> openssl ocsp -issuer /etc/ipa/ca.crt -cert /etc/ipa/ca.crt -text -url
>> http://ipa-ca.exmple.com/ca/ocsp -header "HOST" "ipa.exmple.com"
>> 
>> I was getting a
>> 
>> -END CERTIFICATE-
>> Response verify OK
>> /etc/ipa/ca.crt: good
>> 
>> And there was nothing in the result saying that it was expired on my
>> client machines.
> CA certificate is not revoked, service certificate is. So you are
> verifying status of a wrong certificate in the command above.
> 
>> Can you maybe describe the appropriate way to debug this in the
>> future? I was obviously doing it incorrectly. Which CA logs are you
>> meaning? Are you meaning on the freeIPA servers? Are you meaning the
>> http service itself? Where are you meaning "present in OCSP"? The key
>> to this was my seeing the certificates for the http/service not
>> showing up in the FreeIPA server UI. Once I recreated the http/service
>> certificate the Firefox error went away.
> Since I don't know what your setup is (are you using integrated CA or
> you are trying to use some external CA?), I was trying to give a generic
> answer that would be valid in both cases.
> 
> There is no need to revoke IPA services certificates in the course of
> normal action. So I guess you did that by your explicit act.
> 
> FreeIPA CA (Dogtag) is automatically maintaining its OCSP responder.
> This means when you revoke a certificate, it is added to OCSP at next
> synchronization point in time. After that 'openssl ocsp' command would
> be able to see it is revoked. However, you need to test the right
> certificate -- instead of passing '-cert /etc/ipa/ca.crt', you need to
> pass the cert you want to test for revokation.
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

Welp, I'm an idiot and you are completely 100% correct.

It was indeed revoked, but the http servers certificate was revoked
and not the client..which is where I was focusing 100% of my
debugging. Which clears up a LOT of things. I originally was loading
the ca.crt on an Ubuntu machine a few days prior to this and it was
working completely fine. After a few days I was getting the
"SEC_ERROR_REVOKED_CERTIFICATE" when I went back to try it again.

However, what doesn't make sense to me is all of the commands I was
running to check the certs were telling me that the certs were 100%
okay and not revoked...

I ran this command which is supposedly supposed to tell me if my cert
is okay with OCSP

openssl ocsp -issuer /etc/ipa/ca.crt -cert /etc/ipa/ca.crt -text -url
http://ipa-ca.exmple.com/ca/ocsp -header "HOST" "ipa.exmple.com"

I was getting a

-END CERTIFICATE-
Response verify OK
/etc/ipa/ca.crt: good

And there was nothing in the result saying that it was expired on my
client machines.

https://serverfault.com/questions/590504/how-do-i-check-if-my-ssl-certificates-have-been-revoked

However, when I checked the UI like you suggested, the actual HTTP
servers certificate was no longer listed. Oddly enough I had another
stale browser window up and the certificate was there, BUT I guess in
all of my toying with the the certs in removing them and recreating
them, I guess I deleted all of them, and when I checked the stale page
it showed up. I assume that other than the "valid from:" and the
"valid to:" (which is like 2 years in the future) that a certificate
wouldn't be revoked automatically? I did check on the http server that
certmonger was running and says that "auto-renew: yes".

Can you maybe describe the appropriate way to debug this in the
future? I was obviously doing it incorrectly. Which CA logs are you
meaning? Are you meaning on the freeIPA servers? Are you meaning the
http service itself? Where are you meaning "present in OCSP"? The key
to this was my seeing the certificates for the http/service not
showing up in the FreeIPA server UI. Once I recreated the http/service
certificate the Firefox error went away.

Regardless much appreciated...now to figure out how to handle Ubuntu
since like you said Fedora/CentOS work out of the box with the system
wide certs...


On Sat, Oct 12, 2019 at 12:49 AM Alexander Bokovoy  wrote:
>
> On pe, 11 loka 2019, Kevin Vasko wrote:
> >So following these instructions I found out that the certs are NOT revoked.
> >
> >https://serverfault.com/questions/590504/how-do-i-check-if-my-ssl-certificates-have-been-revoked
> >
> >The one thing I did find is that in Firefox if I uncheck "Query OCSP
> >responder servers to confirm the current validity of certificates".
> >Everything works.
> >
> >Why thats a problem with firefox I'm not sure...I'm still looking into
> >it though...
> As I said, look at the CA that issued that certificate. If it is marked
> as revoked, it would be present in OCSP and also in CA logs *why* it is
> revoked.
>
> If this certificate is issued by IPA CA, go to Web UI, Authentication
> tab, Certificates, and search there for the certificate serial number
> and subject. See the status of it.
>
>
> >
> >
> >On Fri, Oct 11, 2019 at 10:43 AM Kevin Vasko  wrote:
> >>
> >> I'm 100% positive I did nothing with this cert.
> >>
> >> To validate, I spun up a brand new machine completely from scratch.
> >>
> >> 1. ran yum update
> >> 2. installed Gnome
> >> 3. installed ipa with my normal "sudo ipa-client-install
> >> --domain=exaple.com --realm=EXAMPLE.COM --enable-dns-updates
> >> --mkhomedir"
> >> 4. started Gnome with "startx"
> >> 5. Went to URL with Firefox, firefox errored with the
> >> "SEC_ERROR_REVOKED_CERTIFICATE"
> >> 6. installed chrome
> >> 7. went to same URL with Chrome, chrome works.
> >>
> >> LSB Version::core-4.1-amd64:core-4.1-noarch
> >> Distributor ID: CentOS
> >> Description:CentOS Linux release 7.7.1908 (Core)
> >> Release:7.7.1908
> >> Codename:   Core
> >> Linux testmachine.example.com 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon
> >> Sep 30 14:19:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> >> firefox.x86_64  60.9.0-1.el7.centos
> >> @updates
> >> ipa-client.x86_64   4.6.5-11.el7.centos
> >> @base
> >> ipa-client-common.noarch4.6.5-11.el7.centos
> >> @base
> >> ipa-common.noarch   4.6.5-11.el7.centos
> >> @base
> >> chrome-gnome-shell.x86_64   10.1-4.el7 
> >> @base
> >> google-chrome-stable.x86_64 77.0.3865.120-1
> >> @google-chrome
> >>
> >> How can I validate the certificate?
> >>
> >> On Fri, Oct 11, 2019 at 12:11 AM Alexander Bokovoy  
> >> wrote:
> >> >
> >> > On to, 10 loka 2019, Kevin Vasko wrote:
> >> > >So I went back and read, reread, studied what you wrote and I think I’m
> >> > >following you. I’m really unfamiliar with certs and the 

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

So following these instructions I found out that the certs are NOT revoked.

https://serverfault.com/questions/590504/how-do-i-check-if-my-ssl-certificates-have-been-revoked

The one thing I did find is that in Firefox if I uncheck "Query OCSP
responder servers to confirm the current validity of certificates".
Everything works.

Why thats a problem with firefox I'm not sure...I'm still looking into
it though...


On Fri, Oct 11, 2019 at 10:43 AM Kevin Vasko  wrote:
>
> I'm 100% positive I did nothing with this cert.
>
> To validate, I spun up a brand new machine completely from scratch.
>
> 1. ran yum update
> 2. installed Gnome
> 3. installed ipa with my normal "sudo ipa-client-install
> --domain=exaple.com --realm=EXAMPLE.COM --enable-dns-updates
> --mkhomedir"
> 4. started Gnome with "startx"
> 5. Went to URL with Firefox, firefox errored with the
> "SEC_ERROR_REVOKED_CERTIFICATE"
> 6. installed chrome
> 7. went to same URL with Chrome, chrome works.
>
> LSB Version::core-4.1-amd64:core-4.1-noarch
> Distributor ID: CentOS
> Description:CentOS Linux release 7.7.1908 (Core)
> Release:7.7.1908
> Codename:   Core
> Linux testmachine.example.com 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon
> Sep 30 14:19:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> firefox.x86_64  60.9.0-1.el7.centos
> @updates
> ipa-client.x86_64   4.6.5-11.el7.centos@base
> ipa-client-common.noarch4.6.5-11.el7.centos@base
> ipa-common.noarch   4.6.5-11.el7.centos@base
> chrome-gnome-shell.x86_64   10.1-4.el7 @base
> google-chrome-stable.x86_64 77.0.3865.120-1
> @google-chrome
>
> How can I validate the certificate?
>
> On Fri, Oct 11, 2019 at 12:11 AM Alexander Bokovoy  
> wrote:
> >
> > On to, 10 loka 2019, Kevin Vasko wrote:
> > >So I went back and read, reread, studied what you wrote and I think I’m
> > >following you. I’m really unfamiliar with certs and the tools around it
> > >so forgive the ignorance.
> > >
> > >So what I ended up doing is spinning up a CentOS7 VM and installing
> > >everything on it, adding it to the FreeIPA realm etc. and followed your
> > >instructions/email.
> > >
> > >I ran the
> > >
> > >modutil -dbdir sql:./mozilla/firefox/9zd63dro.default/ -list
> > >
> > >It returns the list of the PKCS #11 Modules like I listed in my
> > >previous email. However, it only showed a single item “NSS Internal
> > >PKCS #11 Module”.
> > >
> > >To look at what keys it had I ran
> > >
> > >certutil -d sql:./mozilla/firefox/9zd63dro.default/ -h “NSS Internal PKCS 
> > >#11” -L
> > >
> > >This seemed like it returned all of the system wide certs. Including my
> > >self signed internal lan cert from freeipa. Should it have? That’s
> > >where I’m getting confused with your comment in your email when you
> > >mentioned the p11-kit-proxy and where it’s coming from, how it was
> > >added (if needed) as you said it was providing all of the system wide
> > >certs?
> > >
> > >At this point this is where things took a detour and I think it’s part
> > >of my confusion, which I think is unrelated, but I was using Firefox,
> > >all of the certs are there in the system based on the commands you
> > >showed. However, every time i would visit my http server Firefox would
> > >throw a
> > >
> > >SEC_ERROR_REVOKED_CERTIFICATE
> > >
> > >I pulled my hair out for 2 hours, deleting the .mozilla folder,
> > >recreating it, looking at certs, trying to manually copy certs into the
> > >cert db etc.
> > >
> > >Until I got fed up and tried Chrome...i downloaded chrome installed it
> > >ran it, checked the certs db looked at the certs and verified my
> > >internal cert was listed just like firefox. I visited the http server
> > >in chrome and it worked perfectly. No changes, which I believe is what
> > >you would expect.
> > >
> > >I then went and tried the same thing on Ubuntu. I know you mentioned
> > >that I have to add the certs manually as Ubuntu doesn’t have the same
> > >functionality. So I just manually added my ipa.crt to firefox and then
> > >got a
> > >
> > >SEC_ERROR_REVOKED_CERTIFICATE
> > >
> > >installed chrome on ubuntu machine and manually imported the ipa.crt
> > >into chrome, went to the http and chrome worked fine.
> > >
> > >So now I have no idea where I’m getting this
> > >
> > >SEC_ERROR_REVOKED_CERTIFICATE
> > >
> > >So now on a freeipa realm joined host. It seems that
> > >
> > >CentOS7 -
> > >Firefox gets a  - SEC_ERROR_REVOKED_CERTIFICATE
> > >Chrome -
> > >Works out of the box
> > >
> > >Ubuntu 18.04 -
> > >Firefox gets after manually adding cert- SEC_ERROR_REVOKED_CERTIFICATE
> > >Chrome - works after manually adding the ipa.ca cert through GUI.
> > >
> > >Is there some obvious reason why firefox would throw that error message
> > >but Chrome wouldn’t?
> > >
> > >This stuff is making my head spin.
> >
> > For that host certificate Firefox 

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

I'm 100% positive I did nothing with this cert.

To validate, I spun up a brand new machine completely from scratch.

1. ran yum update
2. installed Gnome
3. installed ipa with my normal "sudo ipa-client-install
--domain=exaple.com --realm=EXAMPLE.COM --enable-dns-updates
--mkhomedir"
4. started Gnome with "startx"
5. Went to URL with Firefox, firefox errored with the
"SEC_ERROR_REVOKED_CERTIFICATE"
6. installed chrome
7. went to same URL with Chrome, chrome works.

LSB Version::core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description:CentOS Linux release 7.7.1908 (Core)
Release:7.7.1908
Codename:   Core
Linux testmachine.example.com 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon
Sep 30 14:19:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
firefox.x86_64  60.9.0-1.el7.centos@updates
ipa-client.x86_64   4.6.5-11.el7.centos@base
ipa-client-common.noarch4.6.5-11.el7.centos@base
ipa-common.noarch   4.6.5-11.el7.centos@base
chrome-gnome-shell.x86_64   10.1-4.el7 @base
google-chrome-stable.x86_64 77.0.3865.120-1
@google-chrome

How can I validate the certificate?

On Fri, Oct 11, 2019 at 12:11 AM Alexander Bokovoy  wrote:
>
> On to, 10 loka 2019, Kevin Vasko wrote:
> >So I went back and read, reread, studied what you wrote and I think I’m
> >following you. I’m really unfamiliar with certs and the tools around it
> >so forgive the ignorance.
> >
> >So what I ended up doing is spinning up a CentOS7 VM and installing
> >everything on it, adding it to the FreeIPA realm etc. and followed your
> >instructions/email.
> >
> >I ran the
> >
> >modutil -dbdir sql:./mozilla/firefox/9zd63dro.default/ -list
> >
> >It returns the list of the PKCS #11 Modules like I listed in my
> >previous email. However, it only showed a single item “NSS Internal
> >PKCS #11 Module”.
> >
> >To look at what keys it had I ran
> >
> >certutil -d sql:./mozilla/firefox/9zd63dro.default/ -h “NSS Internal PKCS 
> >#11” -L
> >
> >This seemed like it returned all of the system wide certs. Including my
> >self signed internal lan cert from freeipa. Should it have? That’s
> >where I’m getting confused with your comment in your email when you
> >mentioned the p11-kit-proxy and where it’s coming from, how it was
> >added (if needed) as you said it was providing all of the system wide
> >certs?
> >
> >At this point this is where things took a detour and I think it’s part
> >of my confusion, which I think is unrelated, but I was using Firefox,
> >all of the certs are there in the system based on the commands you
> >showed. However, every time i would visit my http server Firefox would
> >throw a
> >
> >SEC_ERROR_REVOKED_CERTIFICATE
> >
> >I pulled my hair out for 2 hours, deleting the .mozilla folder,
> >recreating it, looking at certs, trying to manually copy certs into the
> >cert db etc.
> >
> >Until I got fed up and tried Chrome...i downloaded chrome installed it
> >ran it, checked the certs db looked at the certs and verified my
> >internal cert was listed just like firefox. I visited the http server
> >in chrome and it worked perfectly. No changes, which I believe is what
> >you would expect.
> >
> >I then went and tried the same thing on Ubuntu. I know you mentioned
> >that I have to add the certs manually as Ubuntu doesn’t have the same
> >functionality. So I just manually added my ipa.crt to firefox and then
> >got a
> >
> >SEC_ERROR_REVOKED_CERTIFICATE
> >
> >installed chrome on ubuntu machine and manually imported the ipa.crt
> >into chrome, went to the http and chrome worked fine.
> >
> >So now I have no idea where I’m getting this
> >
> >SEC_ERROR_REVOKED_CERTIFICATE
> >
> >So now on a freeipa realm joined host. It seems that
> >
> >CentOS7 -
> >Firefox gets a  - SEC_ERROR_REVOKED_CERTIFICATE
> >Chrome -
> >Works out of the box
> >
> >Ubuntu 18.04 -
> >Firefox gets after manually adding cert- SEC_ERROR_REVOKED_CERTIFICATE
> >Chrome - works after manually adding the ipa.ca cert through GUI.
> >
> >Is there some obvious reason why firefox would throw that error message
> >but Chrome wouldn’t?
> >
> >This stuff is making my head spin.
>
> For that host certificate Firefox thinks it is revoked by its issuer.
> Did you fiddle with the certificates? Perhaps, it would be easier to
> find out what certificate is that and check its status in IPA or whoever
> issued it?
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

t is not really needed
>> anymore if you have p11-kit-proxy on your system. By default
>> p11-kit-proxy has two modules:
>> $ p11-kit list-modules
>> p11-kit-trust: p11-kit-trust.so
>>library-description: PKCS#11 Kit Trust Module
>>library-manufacturer: PKCS#11 Kit
>>library-version: 0.23
>>token: System Trust
>>manufacturer: PKCS#11 Kit
>>model: p11-kit-trust
>>serial-number: 1
>>hardware-version: 0.23
>>flags:
>>   write-protected
>>   token-initialized
>>token: Default Trust
>>manufacturer: PKCS#11 Kit
>>model: p11-kit-trust
>>serial-number: 1
>>hardware-version: 0.23
>>flags:
>>   write-protected
>>   token-initialized
>> opensc: opensc-pkcs11.so
>>library-description: OpenSC smartcard framework
>>library-manufacturer: OpenSC Project
>>library-version: 0.19
>> It is the first one that brings all the system-wide certificates into
>> NSS and other databases. For OpenSSL applications it can be brought in
>> via PKCS#11 engine support.
>>> So I at this point I don't think anything is wrong with
>>> ipa-install-client and it is performing correctly at this point adding
>>> it to the cert store. Given that the exception that you mentioned,
>>> that there is a difference in ipa-install-client adding it to the the
>>> NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian
>>> variants. However, I still don't think that will matter since
>>> Firefox/Chrome aren't reading either the NSS database or the crt
>>> bundle from what I understand.
>>> I'm going to keep digging to see if I find a solution for getting
>>> FF/Chrome to look at my certs and will post back on what I find.
>>> -Kevin
>>> On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy  
>>> wrote:
>>>> On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
>>>>> I actually manually checked the system wide crt files on each
>>>>> distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my
>>>>> /etc/ipa/ca.crt did appear to be in the each of their respective *.crt
>>>>> files. That indicates to me that there isn't any problem with the
>>>>> ipa-install-client on any of the distributions like I originally
>>>>> thought. Rob it does look like Ubuntu is adding it to the
>>>>> /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I
>>>>> didn't do it manually on any of my systems, so it does appear they are
>>>>> doing it somehow.
>>>>> These are the locations I checked.
>>>>> "/etc/ssl/certs/ca-certificates.crt",//
>>>>> Debian/Ubuntu/Gentoo etc.
>>>>> "/etc/pki/tls/certs/ca-bundle.crt",  // Fedora/RHEL 6
>>>>> "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
>>>>> What appears to be the problem is (unless I'm mistaken) Firefox nor
>>>>> Chrome are using the system wide cert locations apparently and only
>>>>> using their own cert store. At least according to this article:
>>>>> https://thomas-leister.de/en/how-to-import-ca-root-certificate/
>>>> On RHEL/Fedora/CentOS we import system wide cert store automatically to
>>>> NSS databases through p11-kit.
>>>> On Ubuntu/Debian/Gentoo you need to do that manually.
>>>>> It kind of is backed up by this article on the Mozilla page.
>>>>> https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
>>>>> So based off of this information I'm going to have to manually add the
>>>>> root certificates to each Chrome and Firefox cert store on the client
>>>>> machines, which is a bummer.
>>>>> Sorry for the noise.
>>>>> On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden  
>>>>> wrote:
>>>>>> Kevin Vasko via FreeIPA-users wrote:
>>>>>>> Kees Bakker,
>>>>>>> If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu
>>>>>>> 18.04 and based on Rob's comment it might not be done if I'm
>>>>>>> understanding him correctly.
>>>>>> Assuming I'm reading the code right it is not being executed on
>>>>>> Debian/Ubuntu. At least not in the source. It's possible it is patched
>>&g

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

only that they use different
> store than Firefox:
>
> $ modutil -dbdir sql:/home/abokovoy/.pki/nssdb -list
>
> Listing of PKCS #11 Modules
> ---
>   1. NSS Internal PKCS #11 Module
>uri: 
> pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46
>  slots: 2 slots attached
> status: loaded
>
>  slot: NSS Internal Cryptographic Services
> token: NSS Generic Crypto Services
>   uri: 
> pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203
>
>  slot: NSS User Private Key and Certificate Services
> token: NSS Certificate DB
>   uri: 
> pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203
>
>   2. DigiSign PKCS#11 Module
> library name: /usr/lib64/libcryptoki.so
>uri: 
> pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1
>  slots: There are no slots attached to this module
> status: loaded
>
>   3. p11-kit-proxy
> library name: p11-kit-proxy.so
>uri: 
> pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1
>  slots: There are no slots attached to this module
> status: loaded
> ---
>
> In past, people did manual work to pick up all the certs like
> https://blog.xelnor.net/firefox-systemcerts/ but it is not really needed
> anymore if you have p11-kit-proxy on your system. By default
> p11-kit-proxy has two modules:
>
> $ p11-kit list-modules
> p11-kit-trust: p11-kit-trust.so
> library-description: PKCS#11 Kit Trust Module
> library-manufacturer: PKCS#11 Kit
> library-version: 0.23
> token: System Trust
> manufacturer: PKCS#11 Kit
> model: p11-kit-trust
> serial-number: 1
> hardware-version: 0.23
> flags:
>write-protected
>token-initialized
> token: Default Trust
> manufacturer: PKCS#11 Kit
> model: p11-kit-trust
> serial-number: 1
> hardware-version: 0.23
> flags:
>write-protected
>token-initialized
> opensc: opensc-pkcs11.so
> library-description: OpenSC smartcard framework
> library-manufacturer: OpenSC Project
> library-version: 0.19
>
> It is the first one that brings all the system-wide certificates into
> NSS and other databases. For OpenSSL applications it can be brought in
> via PKCS#11 engine support.
>
>
> >
> >So I at this point I don't think anything is wrong with
> >ipa-install-client and it is performing correctly at this point adding
> >it to the cert store. Given that the exception that you mentioned,
> >that there is a difference in ipa-install-client adding it to the the
> >NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian
> >variants. However, I still don't think that will matter since
> >Firefox/Chrome aren't reading either the NSS database or the crt
> >bundle from what I understand.
> >
> >I'm going to keep digging to see if I find a solution for getting
> >FF/Chrome to look at my certs and will post back on what I find.
> >
> >-Kevin
> >
> >On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy  
> >wrote:
> >>
> >> On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
> >> >I actually manually checked the system wide crt files on each
> >> >distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my
> >> >/etc/ipa/ca.crt did appear to be in the each of their respective *.crt
> >> >files. That indicates to me that there isn't any problem with the
> >> >ipa-install-client on any of the distributions like I originally
> >> >thought. Rob it does look like Ubuntu is adding it to the
> >> >/etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I
> >> >didn't do it manually on any of my systems, so it does appear they are
> >> >doing it somehow.
> >> >
> >> >These are the locations I checked.
> >> >
> >> >"/etc/ssl/certs/ca-certificates.crt",//
> >> >Debian/Ubuntu/Gentoo etc.
> >> >"/etc/pki/tls/certs/ca-bundle.crt",  // Fedora/RHEL 6
> >> >"/etc

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

Alexander,

Unless I'm misunderstanding the information I don't think it will
matter though because Firefox and Chrome use their own certificates
stores. I found that information after I posted this question.
Speaking specifically for firefox (and Chrome looks to be
similar)...I'm concluding that why I'm not seeing it work is because
of this...

"Since Firefox does not use the operating system's certificate store
by default, these CA certificates must be added in to Firefox using
one of the following methods. " taken from here
https://wiki.mozilla.org/CA/AddRootToFirefox

So I at this point I don't think anything is wrong with
ipa-install-client and it is performing correctly at this point adding
it to the cert store. Given that the exception that you mentioned,
that there is a difference in ipa-install-client adding it to the the
NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian
variants. However, I still don't think that will matter since
Firefox/Chrome aren't reading either the NSS database or the crt
bundle from what I understand.

I'm going to keep digging to see if I find a solution for getting
FF/Chrome to look at my certs and will post back on what I find.

-Kevin

On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy  wrote:
>
> On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
> >I actually manually checked the system wide crt files on each
> >distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my
> >/etc/ipa/ca.crt did appear to be in the each of their respective *.crt
> >files. That indicates to me that there isn't any problem with the
> >ipa-install-client on any of the distributions like I originally
> >thought. Rob it does look like Ubuntu is adding it to the
> >/etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I
> >didn't do it manually on any of my systems, so it does appear they are
> >doing it somehow.
> >
> >These are the locations I checked.
> >
> >"/etc/ssl/certs/ca-certificates.crt",//
> >Debian/Ubuntu/Gentoo etc.
> >"/etc/pki/tls/certs/ca-bundle.crt",  // Fedora/RHEL 6
> >"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
> >
> >What appears to be the problem is (unless I'm mistaken) Firefox nor
> >Chrome are using the system wide cert locations apparently and only
> >using their own cert store. At least according to this article:
> >https://thomas-leister.de/en/how-to-import-ca-root-certificate/
> On RHEL/Fedora/CentOS we import system wide cert store automatically to
> NSS databases through p11-kit.
>
> On Ubuntu/Debian/Gentoo you need to do that manually.
>
> >
> >It kind of is backed up by this article on the Mozilla page.
> >https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
> >
> >So based off of this information I'm going to have to manually add the
> >root certificates to each Chrome and Firefox cert store on the client
> >machines, which is a bummer.
> >
> >Sorry for the noise.
> >
> >On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden  wrote:
> >>
> >> Kevin Vasko via FreeIPA-users wrote:
> >> > Kees Bakker,
> >> >
> >> > If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu
> >> > 18.04 and based on Rob's comment it might not be done if I'm
> >> > understanding him correctly.
> >>
> >> Assuming I'm reading the code right it is not being executed on
> >> Debian/Ubuntu. At least not in the source. It's possible it is patched
> >> into the package in the distribution.
> >>
> >> rob
> >>
> >> >
> >> > -Kevin
> >> >
> >> > On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users
> >> >  wrote:
> >> >>
> >> >> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
> >> >>>
> >> >>> Kevin Vasko via FreeIPA-users wrote:
> >> >>>> How would I validate that certs are getting added properly on a 
> >> >>>> CentOS machine system wide store?
> >> >>>>
> >> >>>>   I’m going to test it today to find out if this is a problem unique 
> >> >>>> to Ubuntu/CentOS.
> >> >>> On Fedora the chain is put into
> >> >>> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is 
> >> >>> executed.
> >> >>>
> >> >>> There is no Debian/Ubuntu equivalent in the upstream source (it's
> >> >>> possible it is 

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

I actually manually checked the system wide crt files on each
distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my
/etc/ipa/ca.crt did appear to be in the each of their respective *.crt
files. That indicates to me that there isn't any problem with the
ipa-install-client on any of the distributions like I originally
thought. Rob it does look like Ubuntu is adding it to the
/etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I
didn't do it manually on any of my systems, so it does appear they are
doing it somehow.

These are the locations I checked.

"/etc/ssl/certs/ca-certificates.crt",//
Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt",  // Fedora/RHEL 6
"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7

What appears to be the problem is (unless I'm mistaken) Firefox nor
Chrome are using the system wide cert locations apparently and only
using their own cert store. At least according to this article:
https://thomas-leister.de/en/how-to-import-ca-root-certificate/

It kind of is backed up by this article on the Mozilla page.
https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox

So based off of this information I'm going to have to manually add the
root certificates to each Chrome and Firefox cert store on the client
machines, which is a bummer.

Sorry for the noise.

On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden  wrote:
>
> Kevin Vasko via FreeIPA-users wrote:
> > Kees Bakker,
> >
> > If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu
> > 18.04 and based on Rob's comment it might not be done if I'm
> > understanding him correctly.
>
> Assuming I'm reading the code right it is not being executed on
> Debian/Ubuntu. At least not in the source. It's possible it is patched
> into the package in the distribution.
>
> rob
>
> >
> > -Kevin
> >
> > On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users
> >  wrote:
> >>
> >> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
> >>>
> >>> Kevin Vasko via FreeIPA-users wrote:
> >>>> How would I validate that certs are getting added properly on a CentOS 
> >>>> machine system wide store?
> >>>>
> >>>>   I’m going to test it today to find out if this is a problem unique to 
> >>>> Ubuntu/CentOS.
> >>> On Fedora the chain is put into
> >>> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is 
> >>> executed.
> >>>
> >>> There is no Debian/Ubuntu equivalent in the upstream source (it's
> >>> possible it is done in packaging). You could try something like:
> >>>
> >>> cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt
> >>> update-ca-certificates
> >> This is already done by ipa-client-install
> >> ___
> >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> >> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> >
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

Kees Bakker,

If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu
18.04 and based on Rob's comment it might not be done if I'm
understanding him correctly.

-Kevin

On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users
 wrote:
>
> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
> >
> > Kevin Vasko via FreeIPA-users wrote:
> >> How would I validate that certs are getting added properly on a CentOS 
> >> machine system wide store?
> >>
> >>   I’m going to test it today to find out if this is a problem unique to 
> >> Ubuntu/CentOS.
> > On Fedora the chain is put into
> > /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
> >
> > There is no Debian/Ubuntu equivalent in the upstream source (it's
> > possible it is done in packaging). You could try something like:
> >
> > cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt
> > update-ca-certificates
> This is already done by ipa-client-install
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

How would I validate that certs are getting added properly on a CentOS machine 
system wide store?

 I’m going to test it today to find out if this is a problem unique to 
Ubuntu/CentOS. 

-Kevin

> On Oct 9, 2019, at 10:44 PM, Fraser Tweedale  wrote:
> 
> On Wed, Oct 09, 2019 at 08:58:14PM -0500, Kevin Vasko wrote:
>> Seems to happen on both Ubuntu 16.04 and 18.04.
>> 
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 16.04.6 LTS
>> Release:16.04
>> Codename:   xenial
>> 
>> $ firefox --version
>> Mozilla Firefox 67.0.4
>> 
>> freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed]
>> freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic]
>> firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64
>> 
>> 
>> 
>> Ubuntu 18.04 machine:
>> 
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 18.04.3 LTS
>> Release:18.04
>> Codename:   bionic
>> 
>> freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed]
>> freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all
>> [installed,automatic]
>> firefox/bionic-updates,bionic-security,now
>> 69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed]
>> 
>> Where is the system trust store located? I was going to validate that
>> the freeipa ca.crt is added to the system trust store. If its not
>> there how do you add the ca.crt to the system trust store?
>> 
>> Should the ipa-install-client command add the system wide trust store?
>> 
> Thanks for the details.  I do not know about system trust on Ubuntu.
> It could be that ipa-client on Ubuntu does add the IPA CA to system
> trust, but the Firefox/Chrome packages ignore the system trust
> store.
> 
> Hopefully someone more familiar with Ubuntu can clarify.
> 
> Cheers,
> Fraser
> 
>> I'll try this on CentOS tomorrow to see if its just an Ubuntu issue.
>> 
>>> On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale  wrote:
>>> 
>>> On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users 
>>> wrote:
>>>> Hello,
>>>> 
>>>> I’m wanting to make our https servers use a trusted certificate within our 
>>>> LAN only. So for example if I have websrv1.ny.example.com when a user uses 
>>>> a machine that’s enrolled into our realm and they visit 
>>>> https://websrv1.ny.example.com they shouldn’t be prompted to accept the 
>>>> self signed certificate.
>>>> 
>>>> I think I’m pretty close but I’m missing a small part.
>>>> 
>>>> The ipa server is all setup and working. Hosts are enrolled to ipa and 
>>>> have the /etc/ipa/ca.crt.
>>>> 
>>>> I have created a service for the http server in IPA. I have obtained a 
>>>> .key file and .crt file for my web server. Those keys for the web server 
>>>> are in the appropriate location and the web server is pointing at the 
>>>> certs correctly.
>>>> 
>>>> On my clients when I go to the web servers URl I am no longer getting a 
>>>> “self signed cert” error message in the browser.
>>>> 
>>>> That message has now changed to “unverified certificate authority”. Which 
>>>> basically indicates to me that the browser doesn’t know if this 
>>>> certificate authority should/can be trusted.
>>>> 
>>>> If i go in the browser (firefox or chrome) in the certificate authority 
>>>> section and import the /etc/ipa/ca.crt i get no errors in the browser 
>>>> about it being unverified.
>>>> 
>>>> So my question is, what am I missing to make the /etc/ipa/ca.crt file 
>>>> globally available for browsers to pick up the certificate automatically?
>>>> 
>>>> when we enroll a host we simply do
>>>> 
>>>> freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
>>>> 
>>>> Accept the defaults, put in the password to enroll and that’s it. Is there 
>>>> something I’m missing?
>>>> 
>>>> -Kevin
>>>> 
>>> Looks like the browser is not using the system trust store.  Please
>>> provide full details of operating system and package versions for
>>> both freeipa and browser packages.
>>> 
>>> Cheers,
>>> Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

Seems to happen on both Ubuntu 16.04 and 18.04.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.6 LTS
Release:16.04
Codename:   xenial

$ firefox --version
Mozilla Firefox 67.0.4

freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed]
freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic]
firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64



Ubuntu 18.04 machine:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.3 LTS
Release:18.04
Codename:   bionic

freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed]
freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all
[installed,automatic]
firefox/bionic-updates,bionic-security,now
69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed]

Where is the system trust store located? I was going to validate that
the freeipa ca.crt is added to the system trust store. If its not
there how do you add the ca.crt to the system trust store?

Should the ipa-install-client command add the system wide trust store?

I'll try this on CentOS tomorrow to see if its just an Ubuntu issue.

On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale  wrote:
>
> On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users wrote:
> > Hello,
> >
> > I’m wanting to make our https servers use a trusted certificate within our 
> > LAN only. So for example if I have websrv1.ny.example.com when a user uses 
> > a machine that’s enrolled into our realm and they visit 
> > https://websrv1.ny.example.com they shouldn’t be prompted to accept the 
> > self signed certificate.
> >
> > I think I’m pretty close but I’m missing a small part.
> >
> > The ipa server is all setup and working. Hosts are enrolled to ipa and have 
> > the /etc/ipa/ca.crt.
> >
> > I have created a service for the http server in IPA. I have obtained a .key 
> > file and .crt file for my web server. Those keys for the web server are in 
> > the appropriate location and the web server is pointing at the certs 
> > correctly.
> >
> > On my clients when I go to the web servers URl I am no longer getting a 
> > “self signed cert” error message in the browser.
> >
> > That message has now changed to “unverified certificate authority”. Which 
> > basically indicates to me that the browser doesn’t know if this certificate 
> > authority should/can be trusted.
> >
> > If i go in the browser (firefox or chrome) in the certificate authority 
> > section and import the /etc/ipa/ca.crt i get no errors in the browser about 
> > it being unverified.
> >
> > So my question is, what am I missing to make the /etc/ipa/ca.crt file 
> > globally available for browsers to pick up the certificate automatically?
> >
> > when we enroll a host we simply do
> >
> > freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
> >
> > Accept the defaults, put in the password to enroll and that’s it. Is there 
> > something I’m missing?
> >
> > -Kevin
> >
> Looks like the browser is not using the system trust store.  Please
> provide full details of operating system and package versions for
> both freeipa and browser packages.
>
> Cheers,
> Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] How to make ipa root certificate available system wide

[Kevin Vasko via FreeIPA-users]

Hello,

I’m wanting to make our https servers use a trusted certificate within our LAN 
only. So for example if I have websrv1.ny.example.com when a user uses a 
machine that’s enrolled into our realm and they visit 
https://websrv1.ny.example.com they shouldn’t be prompted to accept the self 
signed certificate.

I think I’m pretty close but I’m missing a small part.

The ipa server is all setup and working. Hosts are enrolled to ipa and have the 
/etc/ipa/ca.crt.

I have created a service for the http server in IPA. I have obtained a .key 
file and .crt file for my web server. Those keys for the web server are in the 
appropriate location and the web server is pointing at the certs correctly.

On my clients when I go to the web servers URl I am no longer getting a “self 
signed cert” error message in the browser.

That message has now changed to “unverified certificate authority”. Which 
basically indicates to me that the browser doesn’t know if this certificate 
authority should/can be trusted.

If i go in the browser (firefox or chrome) in the certificate authority section 
and import the /etc/ipa/ca.crt i get no errors in the browser about it being 
unverified. 

So my question is, what am I missing to make the /etc/ipa/ca.crt file globally 
available for browsers to pick up the certificate automatically? 

when we enroll a host we simply do

freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir 

Accept the defaults, put in the password to enroll and that’s it. Is there 
something I’m missing?

-Kevin
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Ipa user can't login via ssh

[Kevin Vasko via FreeIPA-users]

Have you made sure your “elham” user has the correct permissions to access the 
machines? Take a look in the UI at the groups/permissions that user elham has. 
Take a look at your HBAC rules as well. That would be my first recommendation 
to check if it was me. 

-Kevin

> On Oct 9, 2019, at 7:23 AM, Elhamsadat Azarian via FreeIPA-users 
>  wrote:
> 
> ### Request for enhancement
> as a Linux admin i want to login into my ipa client with a user that is 
> defined in ipa-server UI.
> 
> ### Issue
> I installed Ipa-server and an Ipa-client on CentOS7.6
> I defined Internal DNS on ipa-server and i defined A and PTR records for 
> client on ipa-server.
> now i can see my client in ipa-UI and i defined a user with name "elham" and 
> i expect that it can login into ipa-client.
> when i login with root in ipa-client and i do sudo elham, it works and kinit 
> elham works too but
> when i do ssh into ipa-client with this user, it show "Access denied"
> i have errors with this context:
> pam_reply : authentication failure to the client
> pam_sss: authentication falure
> 
> im tired of this issue. please help me if you know the solution.
> 
>  Steps to Reproduce
> 1. define new user "elham" in ipa UI
> 2. SSH to ipa-client with elham
> 3. access denied
> 
>  Actual behavior
> (what happens)
> 
>  Expected behavior
> login into ipa-client successfully
> 
>  Version/Release/Distribution
>   ipa-server 4.6.5-11.el7
>   ipa-client 4.6.4-10.el7.centos.3
> Log files and config files are added below:
> 
> 
> 
> krb5.conf
> 
> #File modified by ipa-client-install
> 
> includedir /etc/krb5.conf.d/
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> 
> [logging]
> default = FILE:/var/log/krb5libs.log
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmind.log
> [libdefaults]
> default_realm = LSHS.DC
> dns_lookup_realm = false
> dns_lookup_kdc = false
> rdns = false
> ticket_lifetime = 24h
> forwardable = yes
> allow_weak_crypto = true
> default_ccache_name = KEYRING:persistent:%{uid}
> 
> [realms]
> LSHS.DC = {
> kdc = ipa-irvlt01.example.dc:88
> admin_server = ipa-irvlt01.example.dc:749
> default_domain = example.dc
> }
> [domain_realm]
> .example.com = LSHS.DC
> example.com = LSHS.DC
> 
> 
> 
> sssd.conf
> -
> [domain/example.dc]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = example.dc
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname = ipacli-irvlt01.example.dc
> chpass_provider = ipa
> dyndns_update = True
> ipa_server = _srv_, ipa-irvlt01.example.dc
> dyndns_iface = ens160
> dns_discovery_domain = example.dc
> 
> debug_level = 10
> [sssd]
> ### AFTER IPA ###
> #services = nss, sudo, pam, ssh
> services = nss, pam
> config_file_version = 2
> #
> domains = example.dc
> 
> debug_level = 10
> [nss]
> homedir_substring = /home
> 
> [pam]
> debug_level = 10
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> [secrets]
> 
> [session_recording]
> 
> ##
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA with multiple domains not mappings ids correctly on NFS

[Kevin Vasko via FreeIPA-users]

Thanks for the heads up. I was just changing the config manually. I’ve kind of 
stayed away from automount because i’ve had a lot of trouble wit it on Ubuntu 
boxes. Didn’t actually realize it modifies the idmapd config.

No problem! I posted on Friday so I figured it might be a few days before 
someone even saw this. Thanks for answering. 

-Kevin

> On Oct 7, 2019, at 2:19 PM, François Cami  wrote:
> 
> On Mon, Oct 7, 2019 at 8:39 PM Kevin Vasko via FreeIPA-users
>  wrote:
>> 
>> Ok thanks! I just tried it and that seems to do it! Just using the 
>> “example.com” domain in the idmapd.conf file that is.
>> 
>> I’ll just need to modifying all of my clients idmapd config, which isn’t 
>> that big of deal.
> 
> If you like, newer versions of ipa-client-automount have a new knob to
> specify just that:
> https://pagure.io/freeipa/issue/7918
> 
> Apologies for not seeing this thread earlier.
> 
> François
> 
>> Thanks for the help.
>> 
>> -Kevin
>> 
>>>> On Oct 7, 2019, at 12:13 PM, Simo Sorce  wrote:
>>> 
>>> Hi Kevin,
>>> comments inline.
>>> 
>>>> On Mon, 2019-10-07 at 11:50 -0500, Kevin Vasko wrote:
>>>> Thanks.
>>>> 
>>>> So the clients have different host names depending on where they are 
>>>> located geographically.
>>>> 
>>>> For example
>>>> 
>>>> machines in CA have a FQDN of client1.ca.example.com
>>>> 
>>>> machines in NY have a FQDN of client8.ny.example.com
>>>> 
>>>> They both still belong to the same REALM of EXAMPLE.COM.
>>> 
>>> Good, REALM an domain should be the same in your case IMO.
>>> 
>>> Subdomains are just an organizational tool for you, the actual
>>> authentication/identity domain is the same as the REALM.
>>> 
>>>> In their idmapd.conf file the
>>>> 
>>>> # Domain = hostname.local
>>>> 
>>>> is commented out, and by default it uses the hostnames domain as the value.
>>>> 
>>>> So client1 Domain value by default would be set to ca.example.com and 
>>>> client8 would be set to ny.example.com.
>>>> 
>>>> Should I be listing both ca.example.com AND ny.example.com in their 
>>>> idmapd.conf file?
>>> 
>>> Don't think so
>>> 
>>>> Based off what you are saying I should just be able to get away with 
>>>> listing “Domain = example.com” which is the REALM?
>>> 
>>> Yes, this is what you should do, IMO.
>>> 
>>> Simo.
>>> 
>>>> 
>>>> -Kevin
>>>> 
>>>>>> On Oct 7, 2019, at 11:40 AM, Simo Sorce  wrote:
>>>>> 
>>>>> Note I assume that by "domains" you mean just DNS domains not separate
>>>>> FreeIPA installs, if they are separate installs then it would be a lot
>>>>> more complicated.
>>>>> 
>>>>> Another way that you can handle auth sys is to configure the domain on
>>>>> the server (as any of the domain strings you want) and then use the
>>>>> same domain on all clients), that should make them work.
>>>>> 
>>>>>> On Mon, 2019-10-07 at 12:37 -0400, Simo Sorce via FreeIPA-users wrote:
>>>>>> If you use krb5 authentication you should have no issues, are you using
>>>>>> auth=sys instead ?
>>>>>> 
>>>>>>> On Fri, 2019-10-04 at 17:10 -0500, Kevin Vasko via FreeIPA-users wrote:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> I’ve got FreeIPA setup where I have multiple domains for client 
>>>>>>> machines depending on their geography.
>>>>>>> 
>>>>>>> For example, ca.example.com, and ny.example.com.
>>>>>>> 
>>>>>>> I have a NFS server in nfs-server.ny.example.com and users mapping the 
>>>>>>> NFS server on their clients from ny.example.com and ca.example.com. 
>>>>>>> Users in ny.example.com show files owner:group just fine but users in 
>>>>>>> ca.example.com everything on the nfs server shows nobody:nogroup or 
>>>>>>> nobody: 4294967294
>>>>>>> 
>>>>>>> On the clients I’m seeing this issue on I see these error messages in 
>>>>>>> the log.
>>>>>>> 
>>>>>>> Oct  4 16:53:14 ai

[Freeipa-users] Re: FreeIPA with multiple domains not mappings ids correctly on NFS

[Kevin Vasko via FreeIPA-users]

Ok thanks! I just tried it and that seems to do it! Just using the 
“example.com” domain in the idmapd.conf file that is.

I’ll just need to modifying all of my clients idmapd config, which isn’t that 
big of deal. 

Thanks for the help.

-Kevin

> On Oct 7, 2019, at 12:13 PM, Simo Sorce  wrote:
> 
> Hi Kevin,
> comments inline.
> 
>> On Mon, 2019-10-07 at 11:50 -0500, Kevin Vasko wrote:
>> Thanks.
>> 
>> So the clients have different host names depending on where they are located 
>> geographically.
>> 
>> For example 
>> 
>> machines in CA have a FQDN of client1.ca.example.com
>> 
>> machines in NY have a FQDN of client8.ny.example.com
>> 
>> They both still belong to the same REALM of EXAMPLE.COM.
> 
> Good, REALM an domain should be the same in your case IMO.
> 
> Subdomains are just an organizational tool for you, the actual
> authentication/identity domain is the same as the REALM.
> 
>> In their idmapd.conf file the 
>> 
>> # Domain = hostname.local
>> 
>> is commented out, and by default it uses the hostnames domain as the value.
>> 
>> So client1 Domain value by default would be set to ca.example.com and 
>> client8 would be set to ny.example.com.
>> 
>> Should I be listing both ca.example.com AND ny.example.com in their 
>> idmapd.conf file? 
> 
> Don't think so
> 
>> Based off what you are saying I should just be able to get away with listing 
>> “Domain = example.com” which is the REALM? 
> 
> Yes, this is what you should do, IMO.
> 
> Simo.
> 
>> 
>> -Kevin
>> 
>>>> On Oct 7, 2019, at 11:40 AM, Simo Sorce  wrote:
>>> 
>>> Note I assume that by "domains" you mean just DNS domains not separate
>>> FreeIPA installs, if they are separate installs then it would be a lot
>>> more complicated.
>>> 
>>> Another way that you can handle auth sys is to configure the domain on
>>> the server (as any of the domain strings you want) and then use the
>>> same domain on all clients), that should make them work.
>>> 
>>>> On Mon, 2019-10-07 at 12:37 -0400, Simo Sorce via FreeIPA-users wrote:
>>>> If you use krb5 authentication you should have no issues, are you using
>>>> auth=sys instead ?
>>>> 
>>>>> On Fri, 2019-10-04 at 17:10 -0500, Kevin Vasko via FreeIPA-users wrote:
>>>>> Hello,
>>>>> 
>>>>> I’ve got FreeIPA setup where I have multiple domains for client machines 
>>>>> depending on their geography.
>>>>> 
>>>>> For example, ca.example.com, and ny.example.com. 
>>>>> 
>>>>> I have a NFS server in nfs-server.ny.example.com and users mapping the 
>>>>> NFS server on their clients from ny.example.com and ca.example.com. Users 
>>>>> in ny.example.com show files owner:group just fine but users in 
>>>>> ca.example.com everything on the nfs server shows nobody:nogroup or 
>>>>> nobody: 4294967294
>>>>> 
>>>>> On the clients I’m seeing this issue on I see these error messages in the 
>>>>> log.
>>>>> 
>>>>> Oct  4 16:53:14 aiml1 nfsidmap[7867]: nss_getpwnam: name 
>>>>> ‘u...@ny.example.com' does not map into domain 'ca.example.com’
>>>>> 
>>>>> I did some googling and people are saying to add the domain to 
>>>>> /etc/idmapd.conf but since I already have multiple domains (3 actually) I 
>>>>> don’t see how this will work for all instances unless I can add multiple 
>>>>> domains. I don’t see an obvious way to add multiple domains.
>>>>> 
>>>>> Is there a clean way to handle this?
>>>>> 
>>>>> -Kevin
>>>>> ___
>>>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>>>>> Fedora Code of Conduct: 
>>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>> List Archives: 
>>>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>>>> 
>>>> -- 
>>>> Simo Sorce
>>>> RHEL Crypto Team
>>>> Red Hat, Inc
>>>> 
>>>> 
>>>> 
>>>> ___

[Freeipa-users] Re: FreeIPA with multiple domains not mappings ids correctly on NFS

[Kevin Vasko via FreeIPA-users]

Thanks.

So the clients have different host names depending on where they are located 
geographically.

For example 

machines in CA have a FQDN of client1.ca.example.com

machines in NY have a FQDN of client8.ny.example.com

They both still belong to the same REALM of EXAMPLE.COM.

In their idmapd.conf file the 

# Domain = hostname.local

is commented out, and by default it uses the hostnames domain as the value.

So client1 Domain value by default would be set to ca.example.com and client8 
would be set to ny.example.com.

Should I be listing both ca.example.com AND ny.example.com in their idmapd.conf 
file? 

Based off what you are saying I should just be able to get away with listing 
“Domain = example.com” which is the REALM? 


-Kevin

> On Oct 7, 2019, at 11:40 AM, Simo Sorce  wrote:
> 
> Note I assume that by "domains" you mean just DNS domains not separate
> FreeIPA installs, if they are separate installs then it would be a lot
> more complicated.
> 
> Another way that you can handle auth sys is to configure the domain on
> the server (as any of the domain strings you want) and then use the
> same domain on all clients), that should make them work.
> 
>> On Mon, 2019-10-07 at 12:37 -0400, Simo Sorce via FreeIPA-users wrote:
>> If you use krb5 authentication you should have no issues, are you using
>> auth=sys instead ?
>> 
>>> On Fri, 2019-10-04 at 17:10 -0500, Kevin Vasko via FreeIPA-users wrote:
>>> Hello,
>>> 
>>> I’ve got FreeIPA setup where I have multiple domains for client machines 
>>> depending on their geography.
>>> 
>>> For example, ca.example.com, and ny.example.com. 
>>> 
>>> I have a NFS server in nfs-server.ny.example.com and users mapping the NFS 
>>> server on their clients from ny.example.com and ca.example.com. Users in 
>>> ny.example.com show files owner:group just fine but users in ca.example.com 
>>> everything on the nfs server shows nobody:nogroup or nobody: 4294967294
>>> 
>>> On the clients I’m seeing this issue on I see these error messages in the 
>>> log.
>>> 
>>> Oct  4 16:53:14 aiml1 nfsidmap[7867]: nss_getpwnam: name 
>>> ‘u...@ny.example.com' does not map into domain 'ca.example.com’
>>> 
>>> I did some googling and people are saying to add the domain to 
>>> /etc/idmapd.conf but since I already have multiple domains (3 actually) I 
>>> don’t see how this will work for all instances unless I can add multiple 
>>> domains. I don’t see an obvious way to add multiple domains.
>>> 
>>> Is there a clean way to handle this?
>>> 
>>> -Kevin
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>> 
>> -- 
>> Simo Sorce
>> RHEL Crypto Team
>> Red Hat, Inc
>> 
>> 
>> 
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] FreeIPA with multiple domains not mappings ids correctly on NFS

[Kevin Vasko via FreeIPA-users]

Hello,
 
I’ve got FreeIPA setup where I have multiple domains for client machines 
depending on their geography.
 
For example, ca.example.com, and ny.example.com. 
 
I have a NFS server in nfs-server.ny.example.com and users mapping the NFS 
server on their clients from ny.example.com and ca.example.com. Users in 
ny.example.com show files owner:group just fine but users in ca.example.com 
everything on the nfs server shows nobody:nogroup or nobody: 4294967294
 
On the clients I’m seeing this issue on I see these error messages in the log.
 
Oct  4 16:53:14 aiml1 nfsidmap[7867]: nss_getpwnam: name ‘u...@ny.example.com' 
does not map into domain 'ca.example.com’
 
I did some googling and people are saying to add the domain to /etc/idmapd.conf 
but since I already have multiple domains (3 actually) I don’t see how this 
will work for all instances unless I can add multiple domains. I don’t see an 
obvious way to add multiple domains.
 
Is there a clean way to handle this?

-Kevin___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Issues with config between FreeIPA and Dell EMC Unity NAS server

[Kevin Vasko via FreeIPA-users]

Thanks much! I just tried this and sure enough everything came alive and 
started working as soon as I changed the scheme to what Louis posted in his 
first post. 

The only other thing that I will note is that the Dell EMC seems to hard code 
what is entered for the REALM as the SPN (Service Principle Name). So for 
example I wanted to put this machine as ds1.la.example@ny.example.com, 
however when I type in the host name it automatically put the machine as 
ds1.ny.example@ny.example.com with no way to change it. If I changed what I 
typed into the REALM, it changed the SPN, but obviously that’s not correct. 

I had the hosts name in my FreeIPA system as I intended, not as the Dell EMC 
forces on you, so it wouldn’t authentic correctly. As soon as I changed the 
machine to what Dell EMC puts as the SPN (it’s a grey box that you cant 
change), it started working.

Also thank you Alexander for the information on the differences in the 389 DS 
deployment variants and the explanation on how to get that information.

This seems to be fixed now! Thanks again. 

-Kevin

> On Sep 7, 2019, at 12:20 AM, Louis Abel via FreeIPA-users 
>  wrote:
> 
> A lot of products from vendors actually try to make an assumption on the base 
> layout of an LDAP installation and configuration since they for the most part 
> get configured the same way over and over. If you were to setup 389ds by 
> itself, yes, ou=people,dc=ny,dc=example,dc=com would likely be valid. While 
> FreeIPA does use 389ds, it sets up its tree in a very specific manner.
> 
> Here's an example of what the base layout looks like (while also showing you 
> how to get this information using ldapsearch):
> 
> [label@ipa01 ~]$ kinit label
> Password for la...@example.net:
> [label@ipa01 ~]$ ldapsearch -LLLY GSSAPI -s one dn
> SASL/GSSAPI authentication started
> SASL username: la...@example.net
> SASL SSF: 256
> SASL data security layer installed.
> dn: cn=compat,dc=example,dc=net
> dn: ou=sudoers,dc=example,dc=net
> dn: cn=accounts,dc=example,dc=net
> dn: cn=alt,dc=example,dc=net
> dn: cn=automount,dc=example,dc=net
> dn: cn=hbac,dc=example,dc=net
> dn: cn=sudo,dc=example,dc=net
> dn: cn=etc,dc=example,dc=net
> dn: cn=selinux,dc=example,dc=net
> dn: cn=ca,dc=example,dc=net
> dn: cn=pbac,dc=example,dc=net
> dn: cn=kerberos,dc=example,dc=net
> dn: ou=profile,dc=example,dc=net
> dn: cn=provisioning,dc=example,dc=net
> dn: cn=otp,dc=example,dc=net
> dn: cn=radiusproxy,dc=example,dc=net
> dn: cn=trusts,dc=example,dc=net
> dn: cn=certmap,dc=example,dc=net
> dn: cn=dns,dc=example,dc=net
> 
> All accounts live under cn=accounts by default. You'll end up seeing users, 
> groups, host groups, computer accounts down further.
> 
> [label@ipa01 ~]$ ldapsearch -LLLY GSSAPI -s one -b 
> 'cn=accounts,dc=example,dc=net' dn
> SASL/GSSAPI authentication started
> SASL username: la...@example.net
> SASL SSF: 256
> SASL data security layer installed.
> dn: cn=users,cn=accounts,dc=example,dc=net
> dn: cn=groups,cn=accounts,dc=example,dc=net
> dn: cn=services,cn=accounts,dc=example,dc=net
> dn: cn=computers,cn=accounts,dc=example,dc=net
> dn: cn=hostgroups,cn=accounts,dc=example,dc=net
> dn: cn=cosTemplates,cn=accounts,dc=example,dc=net
> dn: cn=roles,cn=accounts,dc=example,dc=net
> dn: cn=views,cn=accounts,dc=example,dc=net
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Issues with config between FreeIPA and Dell EMC Unity NAS server

[Kevin Vasko via FreeIPA-users]

Thanks Louis! Will be trying this as soon as I get in on Monday (no remote
access). If I wanted to validate my configuration how do I go about getting
this information out of my FreeIPA installation?

Since the EMC by default includes the schema I attached is it old/out of
date or is it for something entirely different?

I was the impression that FreeIPA includes the 389 Directory Service and
that Fedora Directory Service, 389 Directory Service, and FreeIPA Directory
Service were all synonymous.

I'll post back Monday with results. Thanks again.

-Kevin

On Fri, Sep 6, 2019 at 10:30 PM Louis Abel via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> At first glance, it looks like you're doing 1 and 2 correctly. But I'll
> leave that up to someone else to point that out.
>
> As for number 3, those settings are incorrect. What it should look like is
> this:
>
> nss_base_passwdcn=users,cn=accounts,dc=ny,dc=example,dc=com
> nss_base_group cn=groups,cn=accounts,dc=ny,dc=example,dc=com
> nss_base_hosts cn=computers,cn=accounts,dc=ny,dc=example,dc=com
> nss_base_netgroup  cn=ng,cn=alt,dc=ny,dc=example,dc=com
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Issues with config between FreeIPA and Dell EMC Unity NAS server

[Kevin Vasko via FreeIPA-users]

I’m trying to integrate the “NAS Server” on our Dell EMC Unity with our FreeIPA 
server so we can secure our NFS shares. Our FreeIPA server is run of the mill 
setup. We don’t have any special configuration.
 
The Dell EMC Box NAS configuration settings is asking for the following.
 
Realm: 
KDC Servers:
Port:
Base DN:
Custom Principal:
Custom Principal password:
Keytab
 
You can get a better visual from these screenshots. https://imgur.com/a/H6pWemL
 
Info about the environment (I switched example.com from our regular domain but 
it’s a direct replacement).
ny.example.com is my main domain/realm (e.g. NY.EXAMPLE.COM). My other domain 
is la.example.com. My KDC (IPA servers) are ipa.ny.example.com and 
ipa.la.example.com, they are replicas. The Dell EMC Unity NAS server I’m 
setting up will be nfssrv.la.example.com. 
 
So this is what I did. In FreeIPA I create a new host manually through the gui.
 
Principle alias:
nfssrv.la.example@ny.example.com
 
I then created a new service with that host through the gui
 
nfs/nfssrv.la.example@ny.example.com
 
I then went into the freeIPA server and generated a keytab
 
"ipa-getkeytab -s ipa.ny.example.com -p 
nfs/nfssrv.la.example@ny.example.com -k /tmp/nfssrv.keytab -P "
 
The principal in the ipa-getkeytab command and the password I supplied to the 
ipa-getkeytab command is what I supplied in the Dell EMC Unity dialogs.
 
However, when I do all of this, I keep getting errors in the Dell EMC Unity log 
stating
 
“In the NAS server nfssrv.la.example.com, ONE LDAP server for Domain 
ny.example.com goes back from failure.”
“LDAP client settings on NAS server nfssrv.la.example.com are not valid within 
domain ny.example.com”.
 
So the questions I have are.
 
1)  Am I generating the keytab appropriately?
2)  Am I supplying the correct information to the “Specifiy Custom 
principal” “Principal” fields with the principal of the actual server?
3)  The last thing I am unsure about is the “Retrieve Current Schema”. This 
schema was automatically generated. It states is for the Fedora Directory 
Service so I assumed that’s was correct since I’m using CentOS with FreeIPA. I 
haven’t changed anything in the scheme (at least that i’m aware of). Any way to 
validate this? 
 
If anyone can provide any advice/suggestions I would greatly appreciate it.
 
The following is the “Current Schema” listed in the LDAP section.
 
# -
# This template was automatically generated by the EMC Nas server
# - Adjustments could be required to fit your specific LDAP configuration.
 
# - The following setup fits the Fedora Directory service schema.
# Containers
 
nss_base_passwdou=people,dc=ny,dc=example,dc=com
nss_base_group ou=group,dc=ny,dc=example,dc=com
nss_base_hosts ou=hosts, dc=ny,dc=example,dc=com
nss_base_netgroup  ou=netgroup,dc=ny,dc=example,dc=com
 
# - The parameter fast_search allows fast search encoding to boost performances 
with big LDAP repositories.
#   The parameter is set to 1 by default on this configuration,#   Some issue 
could occurs on Microsoft Active Directory server.
#   If you encounter some issue on LDAP lookup, set the value of the parameter 
to 0
fast_search 1


-Kevin___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA 4.5.4 + OpenVPN 2.4.6 + OTP

[Kevin Vasko via FreeIPA-users]

I’m following this because I’m having same issue. Since the OpenVPN client 
won’t prompt twice for the second factor I know you have to do the whole 
“password+otp” (without the +) but keep getting invalid password.

-Kevin

> On Nov 8, 2018, at 12:51 PM, Eric Fredrickson via FreeIPA-users 
>  wrote:
> 
> Hello everyone,
> 
> I'm having an issue with OTP when logging into a vpn server that is a client 
> of FreeIPA.  I can login with no issues when OTP is disabled.
> 
> FreeIPA Setup:
> CentOS 7.5
> FreeIPA 4.5.4
> 
> HBAC Service: openvpn
> HBAC Rule:
> [root@ipa ~]# ipa hbacrule-show openvpn_access
> Rule name: openvpn_access
> Description: VPN users HBAC rule for accessing ,vpnhost> via openvpn service.
> Enabled: TRUE
> Users: 
> Hosts: vpnhost.localdomain.local
> Services: openvpn
> 
> User account:
> [root@ipa ~]# ipa user-show 
>  User login: 
>  First name: 
>  Last name: 
>  Home directory: /home/
>  Login shell: /bin/bash
>  Principal name: 
>  Principal alias: 
>  Email address: 
>  UID: 190963
>  GID: 190963
>  User authentication types: otp
>  Certificate: 
>  Account disabled: False
>  Password: True
>  Member of groups: vpn_users
>  Member of HBAC rule: openvpn_access
>  Indirect Member of HBAC rule: user_ipa_access
>  Kerberos keys available: True
> 
> OpenVPN server:
> /etc/pam.d/openvpn
> #%PAM-1.0
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
> authrequired  pam_env.so
> authrequired  pam_faildelay.so delay=200
> auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 
> 1000 quiet
> auth[default=1 ignore=ignore success=ok] pam_localuser.so
> authsufficientpam_unix.so nullok try_first_pass
> authrequisite pam_succeed_if.so uid >= 1000 quiet_success
> authsufficientpam_sss.so forward_pass
> authrequired  pam_deny.so
> 
> account required  pam_unix.so
> account sufficientpam_localuser.so
> account sufficientpam_succeed_if.so uid < 1000 quiet
> account [default=bad success=ok user_unknown=ignore] pam_sss.so
> account required  pam_permit.so
> 
> passwordrequisite pam_pwquality.so try_first_pass local_users_only 
> retry=3 authtok_type= ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1
> passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass 
> use_authtok
> passwordsufficientpam_sss.so use_authtok
> 
> 
> passwordrequired  pam_deny.so
> 
> session optional  pam_keyinit.so revoke
> session required  pam_limits.so
> -session optional  pam_systemd.so
> session optional  pam_oddjob_mkhomedir.so umask=0077
> session [success=1 default=ignore] pam_succeed_if.so service in crond 
> quiet use_uid
> session required  pam_unix.so
> session optional  pam_sss.so
> 
> server.conf
> plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn
> 
> 
> Any help would be greatly appreciated.  Any other information that you may 
> need, please feel free to ask.  I've read multiple threads, some have gotten 
> it to work without posting answers, some have not and has stated openvpn does 
> not support multiple prompts.
> 
> Eric
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Getting access denied when using kerberos when mounting nfs share

[Kevin Vasko via FreeIPA-users]

I actually ended up figuring this out. For whatever reasons NFS_SECURE=“yes” 
was not in the configuration file (/etc/sysconfig/nfs). Once I added that to 
the configuration on the NFS server and the client (not sure if it’s needed 
there or not) but it started working after resetting all the services. 

Thanks for the reply.

-Kevin

> On Nov 8, 2018, at 12:46 PM, Robbie Harwood  wrote:
> 
> Kevin Vasko via FreeIPA-users 
> writes:
> 
>> I followed these instructions to enable kerberos within my realm/domain. 
>> 
>> My FreeIPA, NFS server and my NFS client is CentOS 7.4
>> 
>> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/kerb-nfs.html
>> 
>> I’m completely stuck in that when I mount the NFS share I get
>> 
>> Sudo mount -o sec=krb5p share.example.com:/data/shared /mnt/shared
>> 
>> “mount.nfs: access denied by server while mounting 
>> share.example.com:/data/shared”
>> 
>> My /etc/exports file
>> /data/shared 172.16.0.0/24(sec=krb5p, rw, ...)
>> 
>> On my nfs server /var/log/messages all i see is
>> 
>> rpc.mountd[1674]: authenticated mount request from 172.16.0.23:819 for 
>> /data/shared (/data/shared)
>> 
>> If i remove the “sec=krb5p” from the mount and the exports file it mounts 
>> just fine.
> 
> What messages to you see from rpc.gssd on the client (assuming you're
> using gssproxy)?  Also, anything in gssproxy logs on the server or
> client?
> 
> Thanks,
> --Robbie
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Getting access denied when using kerberos when mounting nfs share

[Kevin Vasko via FreeIPA-users]

I followed these instructions to enable kerberos within my realm/domain. 

My FreeIPA, NFS server and my NFS client is CentOS 7.4

https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/kerb-nfs.html

I’m completely stuck in that when I mount the NFS share I get

Sudo mount -o sec=krb5p share.example.com:/data/shared /mnt/shared

“mount.nfs: access denied by server while mounting 
share.example.com:/data/shared”

My /etc/exports file
/data/shared 172.16.0.0/24(sec=krb5p, rw, ...)

On my nfs server /var/log/messages all i see is

rpc.mountd[1674]: authenticated mount request from 172.16.0.23:819 for 
/data/shared (/data/shared)

If i remove the “sec=krb5p” from the mount and the exports file it mounts just 
fine.

-Kevin___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org