[Freeipa-users] Re: Free IPA DNS Issues

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:

Hi Rob,

Thanks for your email,

Yeah true FQDN is working without any issues.But is there any way to ssh
via IP as well rather than hostname


Kerberos authentication is based on names of services known to your KDC.
IP address is not a name in this context and is not associated with the
service host/$FQDN, hence it is not found in the Kerberos database.

You can add such service name alias using 'ipa host-add-principal'
command. It is, however, not always enough because most Kerberos
services do not expect to operate with multiple aliases. Luckily, SSH
works fine with such tickets in IPA environment.

$ ipa host-add-principal server.ipa.example host/10.40.1.201
---
Added new aliases to host "server.ipa.example"
---
  Host name: server.ipa.example
  Principal alias: host/server.ipa.example@IPA.EXAMPLE, 
host/10.40.1.201@IPA.EXAMPLE





On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden  wrote:


Pradeep KNS wrote:
> ssh kns@10.40.1.201 -v

[snip]

> SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
> debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such file or
> directory
> debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such file
> or directory
> debug1: Host '10.40.1.201' is known and matches the ED25519 host key.
> debug1: Found key in /var/lib/sss/pubconf/known_hosts:2

The SSSD ssh integration was used to to validate that the host's SSH key
matched what was received so you avoided the "do you trust this host"
prompt. So that's good.

> debug1: rekey out after 4294967296 blocks
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: rekey in after 4294967296 blocks
> debug1: Will attempt key: /home/kns/.ssh/id_rsa
> debug1: Will attempt key: /home/kns/.ssh/id_dsa
> debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
> debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
> debug1: Will attempt key: /home/kns/.ssh/id_ed25519
> debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
> debug1: Will attempt key: /home/kns/.ssh/id_xmss
> debug1: SSH2_MSG_EXT_INFO received
> debug1: kex_input_ext_info:
> server-sig-algs= ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ecdsa-sha2-nistp...@openssh.com
> ,
webauthn-sk-ecdsa-sha2-nistp...@openssh.com
> >
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> debug1: Next authentication method: gssapi-with-mic
> *debug1: Unspecified GSS failure.  Minor code may provide more
information
> Server host/10.40.1@alpha-grep.com
>  not found in Kerberos database*

IPA keys on hostnames, not IP addresses, hence this message. You need to
use a FQDN. AFAIK there is no workaround.

> debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/kns/.ssh/id_rsa
> debug1: Trying private key: /home/kns/.ssh/id_dsa
> debug1: Trying private key: /home/kns/.ssh/id_ecdsa
> debug1: Trying private key: /home/kns/.ssh/id_ecdsa_sk
> debug1: Trying private key: /home/kns/.ssh/id_ed25519
> debug1: Trying private key: /home/kns/.ssh/id_ed25519_sk
> debug1: Trying private key: /home/kns/.ssh/id_xmss
> debug1: Next authentication method: keyboard-interactive
> (kns@10.40.1.201 ) Password:

It failed to do a Kerberos/GSSAPI auth so it fell back to password.

rob







--
/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Free IPA DNS Issues

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 03 кас 2023, Pradeep KNS wrote:

Hi Alexander,

Thanks for your email,
Like this i need to add all servers? As my dns is located in internal
different server.


Only if you need to use Kerberos authentication.



Also if i want to jump from one server to another server on ipa clients
using sshkeybased? How this mechanism works? here


If you are using SSH keypairs, you are not using Kerberos and thus don't
need these aliases at all.

If you want to use SSH keypair to authenticate, then upload public SSH
key for that user to IPA.

In general, almost all these details covered in the RHEL IdM
documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/managing-public-ssh-keys_managing-users-groups-hosts






On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
wrote:


Awesome, thanks for the info!

On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
wrote:


On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
>Hi Rob,
>
>Thanks for your email,
>
>Yeah true FQDN is working without any issues.But is there any way to ssh
>via IP as well rather than hostname

Kerberos authentication is based on names of services known to your KDC.
IP address is not a name in this context and is not associated with the
service host/$FQDN, hence it is not found in the Kerberos database.

You can add such service name alias using 'ipa host-add-principal'
command. It is, however, not always enough because most Kerberos
services do not expect to operate with multiple aliases. Luckily, SSH
works fine with such tickets in IPA environment.

$ ipa host-add-principal server.ipa.example host/10.40.1.201
---
Added new aliases to host "server.ipa.example"
---
   Host name: server.ipa.example
   Principal alias: host/server.ipa.example@IPA.EXAMPLE,
host/10.40.1.201@IPA.EXAMPLE



>
>On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden 
wrote:
>
>> Pradeep KNS wrote:
>> > ssh kns@10.40.1.201 -v
>>
>> [snip]
>>
>> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
>> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such
file or
>> > directory
>> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such
file
>> > or directory
>> > debug1: Host '10.40.1.201' is known and matches the ED25519 host key.
>> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
>>
>> The SSSD ssh integration was used to to validate that the host's SSH
key
>> matched what was received so you avoided the "do you trust this host"
>> prompt. So that's good.
>>
>> > debug1: rekey out after 4294967296 blocks
>> > debug1: SSH2_MSG_NEWKEYS sent
>> > debug1: expecting SSH2_MSG_NEWKEYS
>> > debug1: SSH2_MSG_NEWKEYS received
>> > debug1: rekey in after 4294967296 blocks
>> > debug1: Will attempt key: /home/kns/.ssh/id_rsa
>> > debug1: Will attempt key: /home/kns/.ssh/id_dsa
>> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
>> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
>> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519
>> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
>> > debug1: Will attempt key: /home/kns/.ssh/id_xmss
>> > debug1: SSH2_MSG_EXT_INFO received
>> > debug1: kex_input_ext_info:
>> > server-sig-algs=> > >
>,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
>> sk-ecdsa-sha2-nistp...@openssh.com
>> > ,
>> webauthn-sk-ecdsa-sha2-nistp...@openssh.com
>> > >
>> > debug1: SSH2_MSG_SERVICE_ACCEPT received
>> > debug1: Authentications that can continue:
>> > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
>> > debug1: Next authentication method: gssapi-with-mic
>> > *debug1: Unspecified GSS failure.  Minor code may provide more
>> information
>> > Server host/10.40.1@alpha-grep.com
>> >  not found in Kerberos database*
>>
>> IPA keys on hostnames, not IP addresses, hence this message. You need
to
>> use a FQDN. AFAIK there is no workaround.
>>
>> > debug1: Authentications that can continue:
>> > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
>> > debug1: Next authentication method: publickey
>> > debug1: Trying private key: /home/kns/.ssh/id_rsa
>> > debug1: Trying private key: /home/kns/.ssh/id_dsa
>> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa
>> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa_sk
>> > debug1: Trying private key: /home/kns/.ssh/id_ed25519
>> > debug1: Trying private key: /home/kns/.ssh/id_ed25519_sk
>> > debug1: Trying private key: /home/kns/.ssh/id_xmss
>> > debug1: Next authentication method: keyboard-interactive
>> > (kns@10.40.1.201 ) Password:
>>
>> It failed to do a Kerberos/GSSAPI auth so it fell back to password.
>>
>> rob
>>
>>

[Freeipa-users] Re: Free IPA DNS Issues

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 03 кас 2023, Pradeep KNS wrote:

Thanks for the information.
Will go through the document.

But if i add the public key i am able authenticate from server A to server
B and C from same Server A.

But if i want to communicate in-between Server B to Server C how this ipa
will work? should i want to copy my pvt key?? Across all the hosts so that
internal communication will happens?


It happens exactly same way as you'd do that without IPA. Something
should provide access to that private key. Typically people achieve that
by forwarding SSH authentication agent connection. Look at man page for
ssh about authentication agent.




On Tue, 3 Oct 2023 at 2:11 PM, Alexander Bokovoy 
wrote:


On Аўт, 03 кас 2023, Pradeep KNS wrote:
>Hi Alexander,
>
>Thanks for your email,
>Like this i need to add all servers? As my dns is located in internal
>different server.

Only if you need to use Kerberos authentication.

>
>Also if i want to jump from one server to another server on ipa clients
>using sshkeybased? How this mechanism works? here

If you are using SSH keypairs, you are not using Kerberos and thus don't
need these aliases at all.

If you want to use SSH keypair to authenticate, then upload public SSH
key for that user to IPA.

In general, almost all these details covered in the RHEL IdM
documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/managing-public-ssh-keys_managing-users-groups-hosts

>
>
>
>
>On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
>wrote:
>
>> Awesome, thanks for the info!
>>
>> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
>> wrote:
>>
>>> On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
>>> >Hi Rob,
>>> >
>>> >Thanks for your email,
>>> >
>>> >Yeah true FQDN is working without any issues.But is there any way to
ssh
>>> >via IP as well rather than hostname
>>>
>>> Kerberos authentication is based on names of services known to your
KDC.
>>> IP address is not a name in this context and is not associated with the
>>> service host/$FQDN, hence it is not found in the Kerberos database.
>>>
>>> You can add such service name alias using 'ipa host-add-principal'
>>> command. It is, however, not always enough because most Kerberos
>>> services do not expect to operate with multiple aliases. Luckily, SSH
>>> works fine with such tickets in IPA environment.
>>>
>>> $ ipa host-add-principal server.ipa.example host/10.40.1.201
>>> ---
>>> Added new aliases to host "server.ipa.example"
>>> ---
>>>Host name: server.ipa.example
>>>Principal alias: host/server.ipa.example@IPA.EXAMPLE,
>>> host/10.40.1.201@IPA.EXAMPLE
>>>
>>>
>>>
>>> >
>>> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden 
>>> wrote:
>>> >
>>> >> Pradeep KNS wrote:
>>> >> > ssh kns@10.40.1.201 -v
>>> >>
>>> >> [snip]
>>> >>
>>> >> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
>>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such
>>> file or
>>> >> > directory
>>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such
>>> file
>>> >> > or directory
>>> >> > debug1: Host '10.40.1.201' is known and matches the ED25519 host
key.
>>> >> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
>>> >>
>>> >> The SSSD ssh integration was used to to validate that the host's SSH
>>> key
>>> >> matched what was received so you avoided the "do you trust this
host"
>>> >> prompt. So that's good.
>>> >>
>>> >> > debug1: rekey out after 4294967296 blocks
>>> >> > debug1: SSH2_MSG_NEWKEYS sent
>>> >> > debug1: expecting SSH2_MSG_NEWKEYS
>>> >> > debug1: SSH2_MSG_NEWKEYS received
>>> >> > debug1: rekey in after 4294967296 blocks
>>> >> > debug1: Will attempt key: /home/kns/.ssh/id_rsa
>>> >> > debug1: Will attempt key: /home/kns/.ssh/id_dsa
>>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
>>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
>>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519
>>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
>>> >> > debug1: Will attempt key: /home/kns/.ssh/id_xmss
>>> >> > debug1: SSH2_MSG_EXT_INFO received
>>> >> > debug1: kex_input_ext_info:
>>> >> > server-sig-algs=>> >> > >> >>
>>>
>,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
>>> >> sk-ecdsa-sha2-nistp...@openssh.com
>>> >> > ,
>>> >> webauthn-sk-ecdsa-sha2-nistp...@openssh.com
>>> >> > >
>>> >> > debug1: SSH2_MSG_SERVICE_ACCEPT received
>>> >> > debug1: Authentications that can continue:
>>> >> >
publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
>>> >> > debug1: Next authentication method: gssapi-with-mic
>>> >> > *debug1: Unspecified GSS failure.  Minor code may provide more
>>> >> information

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

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

> On 2 Oct 2023, at 15:12, Kees Bakker via FreeIPA-users 
>  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.

Best,

Francis 
___
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: FreeIPA and TrueNAS Scale for mounting of nfs4 shares

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 03 кас 2023, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:




On 2 Oct 2023, at 15:12, Kees Bakker via FreeIPA-users 
 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.

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.


--
/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

> 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 
>>>  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 TrueNAS side, but I tried with all types of ACL to 
no avail.

Best,

Francis  ___
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: Free IPA DNS Issues

[Pradeep KNS via FreeIPA-users]

Awesome, thanks for the info!

On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
wrote:

> On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
> >Hi Rob,
> >
> >Thanks for your email,
> >
> >Yeah true FQDN is working without any issues.But is there any way to ssh
> >via IP as well rather than hostname
>
> Kerberos authentication is based on names of services known to your KDC.
> IP address is not a name in this context and is not associated with the
> service host/$FQDN, hence it is not found in the Kerberos database.
>
> You can add such service name alias using 'ipa host-add-principal'
> command. It is, however, not always enough because most Kerberos
> services do not expect to operate with multiple aliases. Luckily, SSH
> works fine with such tickets in IPA environment.
>
> $ ipa host-add-principal server.ipa.example host/10.40.1.201
> ---
> Added new aliases to host "server.ipa.example"
> ---
>Host name: server.ipa.example
>Principal alias: host/server.ipa.example@IPA.EXAMPLE,
> host/10.40.1.201@IPA.EXAMPLE
>
>
>
> >
> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden 
> wrote:
> >
> >> Pradeep KNS wrote:
> >> > ssh kns@10.40.1.201 -v
> >>
> >> [snip]
> >>
> >> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such file
> or
> >> > directory
> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such file
> >> > or directory
> >> > debug1: Host '10.40.1.201' is known and matches the ED25519 host key.
> >> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
> >>
> >> The SSSD ssh integration was used to to validate that the host's SSH key
> >> matched what was received so you avoided the "do you trust this host"
> >> prompt. So that's good.
> >>
> >> > debug1: rekey out after 4294967296 blocks
> >> > debug1: SSH2_MSG_NEWKEYS sent
> >> > debug1: expecting SSH2_MSG_NEWKEYS
> >> > debug1: SSH2_MSG_NEWKEYS received
> >> > debug1: rekey in after 4294967296 blocks
> >> > debug1: Will attempt key: /home/kns/.ssh/id_rsa
> >> > debug1: Will attempt key: /home/kns/.ssh/id_dsa
> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519
> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
> >> > debug1: Will attempt key: /home/kns/.ssh/id_xmss
> >> > debug1: SSH2_MSG_EXT_INFO received
> >> > debug1: kex_input_ext_info:
> >> > server-sig-algs= >> >  >>
> >,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> >> sk-ecdsa-sha2-nistp...@openssh.com
> >> > ,
> >> webauthn-sk-ecdsa-sha2-nistp...@openssh.com
> >> > >
> >> > debug1: SSH2_MSG_SERVICE_ACCEPT received
> >> > debug1: Authentications that can continue:
> >> > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> >> > debug1: Next authentication method: gssapi-with-mic
> >> > *debug1: Unspecified GSS failure.  Minor code may provide more
> >> information
> >> > Server host/10.40.1@alpha-grep.com
> >> >  not found in Kerberos database*
> >>
> >> IPA keys on hostnames, not IP addresses, hence this message. You need to
> >> use a FQDN. AFAIK there is no workaround.
> >>
> >> > debug1: Authentications that can continue:
> >> > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> >> > debug1: Next authentication method: publickey
> >> > debug1: Trying private key: /home/kns/.ssh/id_rsa
> >> > debug1: Trying private key: /home/kns/.ssh/id_dsa
> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa
> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa_sk
> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519
> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519_sk
> >> > debug1: Trying private key: /home/kns/.ssh/id_xmss
> >> > debug1: Next authentication method: keyboard-interactive
> >> > (kns@10.40.1.201 ) Password:
> >>
> >> It failed to do a Kerberos/GSSAPI auth so it fell back to password.
> >>
> >> rob
> >>
> >>
>
>
>
>
> --
> / 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issu

[Freeipa-users] Re: Free IPA DNS Issues

[Pradeep KNS via FreeIPA-users]

Hi Alexander,

Thanks for your email,
Like this i need to add all servers? As my dns is located in internal
different server.

Also if i want to jump from one server to another server on ipa clients
using sshkeybased? How this mechanism works? here




On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
wrote:

> Awesome, thanks for the info!
>
> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
> wrote:
>
>> On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
>> >Hi Rob,
>> >
>> >Thanks for your email,
>> >
>> >Yeah true FQDN is working without any issues.But is there any way to ssh
>> >via IP as well rather than hostname
>>
>> Kerberos authentication is based on names of services known to your KDC.
>> IP address is not a name in this context and is not associated with the
>> service host/$FQDN, hence it is not found in the Kerberos database.
>>
>> You can add such service name alias using 'ipa host-add-principal'
>> command. It is, however, not always enough because most Kerberos
>> services do not expect to operate with multiple aliases. Luckily, SSH
>> works fine with such tickets in IPA environment.
>>
>> $ ipa host-add-principal server.ipa.example host/10.40.1.201
>> ---
>> Added new aliases to host "server.ipa.example"
>> ---
>>Host name: server.ipa.example
>>Principal alias: host/server.ipa.example@IPA.EXAMPLE,
>> host/10.40.1.201@IPA.EXAMPLE
>>
>>
>>
>> >
>> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden 
>> wrote:
>> >
>> >> Pradeep KNS wrote:
>> >> > ssh kns@10.40.1.201 -v
>> >>
>> >> [snip]
>> >>
>> >> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such
>> file or
>> >> > directory
>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such
>> file
>> >> > or directory
>> >> > debug1: Host '10.40.1.201' is known and matches the ED25519 host key.
>> >> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
>> >>
>> >> The SSSD ssh integration was used to to validate that the host's SSH
>> key
>> >> matched what was received so you avoided the "do you trust this host"
>> >> prompt. So that's good.
>> >>
>> >> > debug1: rekey out after 4294967296 blocks
>> >> > debug1: SSH2_MSG_NEWKEYS sent
>> >> > debug1: expecting SSH2_MSG_NEWKEYS
>> >> > debug1: SSH2_MSG_NEWKEYS received
>> >> > debug1: rekey in after 4294967296 blocks
>> >> > debug1: Will attempt key: /home/kns/.ssh/id_rsa
>> >> > debug1: Will attempt key: /home/kns/.ssh/id_dsa
>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519
>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
>> >> > debug1: Will attempt key: /home/kns/.ssh/id_xmss
>> >> > debug1: SSH2_MSG_EXT_INFO received
>> >> > debug1: kex_input_ext_info:
>> >> > server-sig-algs=> >> > > >>
>> >,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
>> >> sk-ecdsa-sha2-nistp...@openssh.com
>> >> > ,
>> >> webauthn-sk-ecdsa-sha2-nistp...@openssh.com
>> >> > >
>> >> > debug1: SSH2_MSG_SERVICE_ACCEPT received
>> >> > debug1: Authentications that can continue:
>> >> > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
>> >> > debug1: Next authentication method: gssapi-with-mic
>> >> > *debug1: Unspecified GSS failure.  Minor code may provide more
>> >> information
>> >> > Server host/10.40.1@alpha-grep.com
>> >> >  not found in Kerberos database*
>> >>
>> >> IPA keys on hostnames, not IP addresses, hence this message. You need
>> to
>> >> use a FQDN. AFAIK there is no workaround.
>> >>
>> >> > debug1: Authentications that can continue:
>> >> > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
>> >> > debug1: Next authentication method: publickey
>> >> > debug1: Trying private key: /home/kns/.ssh/id_rsa
>> >> > debug1: Trying private key: /home/kns/.ssh/id_dsa
>> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa
>> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa_sk
>> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519
>> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519_sk
>> >> > debug1: Trying private key: /home/kns/.ssh/id_xmss
>> >> > debug1: Next authentication method: keyboard-interactive
>> >> > (kns@10.40.1.201 ) Password:
>> >>
>> >> It failed to do a Kerberos/GSSAPI auth so it fell back to password.
>> >>
>> >> rob
>> >>
>> >>
>>
>>
>>
>>
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland
>>
>>
___
FreeIPA-users mailing list -- freeipa-users@lis

[Freeipa-users] Re: Free IPA DNS Issues

[Pradeep KNS via FreeIPA-users]

Thanks for the information.
Will go through the document.

But if i add the public key i am able authenticate from server A to server
B and C from same Server A.

But if i want to communicate in-between Server B to Server C how this ipa
will work? should i want to copy my pvt key?? Across all the hosts so that
internal communication will happens?


On Tue, 3 Oct 2023 at 2:11 PM, Alexander Bokovoy 
wrote:

> On Аўт, 03 кас 2023, Pradeep KNS wrote:
> >Hi Alexander,
> >
> >Thanks for your email,
> >Like this i need to add all servers? As my dns is located in internal
> >different server.
>
> Only if you need to use Kerberos authentication.
>
> >
> >Also if i want to jump from one server to another server on ipa clients
> >using sshkeybased? How this mechanism works? here
>
> If you are using SSH keypairs, you are not using Kerberos and thus don't
> need these aliases at all.
>
> If you want to use SSH keypair to authenticate, then upload public SSH
> key for that user to IPA.
>
> In general, almost all these details covered in the RHEL IdM
> documentation:
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/managing-public-ssh-keys_managing-users-groups-hosts
>
> >
> >
> >
> >
> >On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
> >wrote:
> >
> >> Awesome, thanks for the info!
> >>
> >> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
> >> wrote:
> >>
> >>> On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
> >>> >Hi Rob,
> >>> >
> >>> >Thanks for your email,
> >>> >
> >>> >Yeah true FQDN is working without any issues.But is there any way to
> ssh
> >>> >via IP as well rather than hostname
> >>>
> >>> Kerberos authentication is based on names of services known to your
> KDC.
> >>> IP address is not a name in this context and is not associated with the
> >>> service host/$FQDN, hence it is not found in the Kerberos database.
> >>>
> >>> You can add such service name alias using 'ipa host-add-principal'
> >>> command. It is, however, not always enough because most Kerberos
> >>> services do not expect to operate with multiple aliases. Luckily, SSH
> >>> works fine with such tickets in IPA environment.
> >>>
> >>> $ ipa host-add-principal server.ipa.example host/10.40.1.201
> >>> ---
> >>> Added new aliases to host "server.ipa.example"
> >>> ---
> >>>Host name: server.ipa.example
> >>>Principal alias: host/server.ipa.example@IPA.EXAMPLE,
> >>> host/10.40.1.201@IPA.EXAMPLE
> >>>
> >>>
> >>>
> >>> >
> >>> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden 
> >>> wrote:
> >>> >
> >>> >> Pradeep KNS wrote:
> >>> >> > ssh kns@10.40.1.201 -v
> >>> >>
> >>> >> [snip]
> >>> >>
> >>> >> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such
> >>> file or
> >>> >> > directory
> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such
> >>> file
> >>> >> > or directory
> >>> >> > debug1: Host '10.40.1.201' is known and matches the ED25519 host
> key.
> >>> >> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
> >>> >>
> >>> >> The SSSD ssh integration was used to to validate that the host's SSH
> >>> key
> >>> >> matched what was received so you avoided the "do you trust this
> host"
> >>> >> prompt. So that's good.
> >>> >>
> >>> >> > debug1: rekey out after 4294967296 blocks
> >>> >> > debug1: SSH2_MSG_NEWKEYS sent
> >>> >> > debug1: expecting SSH2_MSG_NEWKEYS
> >>> >> > debug1: SSH2_MSG_NEWKEYS received
> >>> >> > debug1: rekey in after 4294967296 blocks
> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_rsa
> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_dsa
> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519
> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_xmss
> >>> >> > debug1: SSH2_MSG_EXT_INFO received
> >>> >> > debug1: kex_input_ext_info:
> >>> >> > server-sig-algs= >>> >> >  >>> >>
> >>>
> >,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> >>> >> sk-ecdsa-sha2-nistp...@openssh.com
> >>> >> > ,
> >>> >> webauthn-sk-ecdsa-sha2-nistp...@openssh.com
> >>> >> > >
> >>> >> > debug1: SSH2_MSG_SERVICE_ACCEPT received
> >>> >> > debug1: Authentications that can continue:
> >>> >> >
> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> >>> >> > debug1: Next authentication method: gssapi-with-mic
> >>> >> > *debug1: Unspecified GSS failure.  Minor code may provide more
> >>> >> information
> >>> >> > Server host/10.40.1@alpha-grep.com
> >>> >

[Freeipa-users] Re: Free IPA DNS Issues

[Pradeep KNS via FreeIPA-users]

Thanks Alexander,Thanks for the info

On Tue, 3 Oct 2023 at 2:21 PM, Alexander Bokovoy 
wrote:

> On Аўт, 03 кас 2023, Pradeep KNS wrote:
> >Thanks for the information.
> >Will go through the document.
> >
> >But if i add the public key i am able authenticate from server A to server
> >B and C from same Server A.
> >
> >But if i want to communicate in-between Server B to Server C how this ipa
> >will work? should i want to copy my pvt key?? Across all the hosts so that
> >internal communication will happens?
>
> It happens exactly same way as you'd do that without IPA. Something
> should provide access to that private key. Typically people achieve that
> by forwarding SSH authentication agent connection. Look at man page for
> ssh about authentication agent.
>
> >
> >
> >On Tue, 3 Oct 2023 at 2:11 PM, Alexander Bokovoy 
> >wrote:
> >
> >> On Аўт, 03 кас 2023, Pradeep KNS wrote:
> >> >Hi Alexander,
> >> >
> >> >Thanks for your email,
> >> >Like this i need to add all servers? As my dns is located in internal
> >> >different server.
> >>
> >> Only if you need to use Kerberos authentication.
> >>
> >> >
> >> >Also if i want to jump from one server to another server on ipa clients
> >> >using sshkeybased? How this mechanism works? here
> >>
> >> If you are using SSH keypairs, you are not using Kerberos and thus don't
> >> need these aliases at all.
> >>
> >> If you want to use SSH keypair to authenticate, then upload public SSH
> >> key for that user to IPA.
> >>
> >> In general, almost all these details covered in the RHEL IdM
> >> documentation:
> >>
> >>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/managing-public-ssh-keys_managing-users-groups-hosts
> >>
> >> >
> >> >
> >> >
> >> >
> >> >On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS  >
> >> >wrote:
> >> >
> >> >> Awesome, thanks for the info!
> >> >>
> >> >> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy <
> aboko...@redhat.com>
> >> >> wrote:
> >> >>
> >> >>> On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
> >> >>> >Hi Rob,
> >> >>> >
> >> >>> >Thanks for your email,
> >> >>> >
> >> >>> >Yeah true FQDN is working without any issues.But is there any way
> to
> >> ssh
> >> >>> >via IP as well rather than hostname
> >> >>>
> >> >>> Kerberos authentication is based on names of services known to your
> >> KDC.
> >> >>> IP address is not a name in this context and is not associated with
> the
> >> >>> service host/$FQDN, hence it is not found in the Kerberos database.
> >> >>>
> >> >>> You can add such service name alias using 'ipa host-add-principal'
> >> >>> command. It is, however, not always enough because most Kerberos
> >> >>> services do not expect to operate with multiple aliases. Luckily,
> SSH
> >> >>> works fine with such tickets in IPA environment.
> >> >>>
> >> >>> $ ipa host-add-principal server.ipa.example host/10.40.1.201
> >> >>> ---
> >> >>> Added new aliases to host "server.ipa.example"
> >> >>> ---
> >> >>>Host name: server.ipa.example
> >> >>>Principal alias: host/server.ipa.example@IPA.EXAMPLE,
> >> >>> host/10.40.1.201@IPA.EXAMPLE
> >> >>>
> >> >>>
> >> >>>
> >> >>> >
> >> >>> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden  >
> >> >>> wrote:
> >> >>> >
> >> >>> >> Pradeep KNS wrote:
> >> >>> >> > ssh kns@10.40.1.201 -v
> >> >>> >>
> >> >>> >> [snip]
> >> >>> >>
> >> >>> >> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
> >> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No
> such
> >> >>> file or
> >> >>> >> > directory
> >> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No
> such
> >> >>> file
> >> >>> >> > or directory
> >> >>> >> > debug1: Host '10.40.1.201' is known and matches the ED25519
> host
> >> key.
> >> >>> >> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
> >> >>> >>
> >> >>> >> The SSSD ssh integration was used to to validate that the host's
> SSH
> >> >>> key
> >> >>> >> matched what was received so you avoided the "do you trust this
> >> host"
> >> >>> >> prompt. So that's good.
> >> >>> >>
> >> >>> >> > debug1: rekey out after 4294967296 blocks
> >> >>> >> > debug1: SSH2_MSG_NEWKEYS sent
> >> >>> >> > debug1: expecting SSH2_MSG_NEWKEYS
> >> >>> >> > debug1: SSH2_MSG_NEWKEYS received
> >> >>> >> > debug1: rekey in after 4294967296 blocks
> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_rsa
> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_dsa
> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519
> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_xmss
> >> >>> >> > debug1: SSH2_MSG_EXT_INFO received
> >> >>> >> > debug1: kex_input_ext_info:
> >> >>> >> > serve

[Freeipa-users] FreeIPA 4.11.0

[Antonio Torres via FreeIPA-users]

The FreeIPA team would like to announce the FreeIPA 4.11.0 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
for Fedora distributions will be available from the official repository
soon.

The full release notes can be found at:

https://www.freeipa.org/release-notes/4-11-0.html
___
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: 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 TrueNAS