10:24 a.m.
Hello,
I have an IPA cluster of 5 servers, running version 4.9.6-10. The
system was put in production Feb 2021 and has been updated several
times. These updates have sometimes not gone well:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
I'll try to keep this concise. A user was not able to access an NFS
share provided by our EMC Isilon. They were a member of the group that
owned the directory/share. But not always, it depended upon what Isilon
IP was mounted. After many hours of troubleshooting, we found the group
was newly created and different than our old groups.
The group had an attribute we are not yet familiar with:
ipaNTSecurityIdentifier
The group also had an objectClass none of our others have: ipaNTGroupAttrs
This brought to my attention an issue I saw last week when trying to add
an IPA replica to our cluster. This is new prompting that I have not
seen before while setting up replicas:
WARNING: 1755 existing users or groups do not have a SID identifier
assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man
page
for details.
Do you want to run the ipa-sidgen task? [no]:
----
I'm trying to understand the thread "Login failed due to an unknown
reason"
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
where Alexander explains how to fix SIDs. Also there is a thread: IPA
WebGUI login fails with "Login failed due to an unknown reason".
Are SIDs now required? An aside, in one of my install-replica attempts
last week I was asked to provide a NetBIOS name. :(
My IPA cluster is now wanting to do these SMB/AD sorts of things. Newly
created groups now have ipaNTSecurityIdentifier, which causes permission
issues when mounting NFS on our Isilon. Are we forced down this road or
do I have something misconfigured that is "half-way" doing AD? I'd like
to learn about the big picture.
Thank you,
Scott Serr
2:40 p.m.
New subject: Group permissions failing on group with ipaNTSecurityIdentifier attribute
On ti, 01 helmi 2022, Scott Serr via FreeIPA-users wrote:
Hello,
I have an IPA cluster of 5 servers, running version 4.9.6-10. The
system was put in production Feb 2021 and has been updated several
times. These updates have sometimes not gone well:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
I'll try to keep this concise. A user was not able to access an NFS
share provided by our EMC Isilon. They were a member of the group
that owned the directory/share. But not always, it depended upon what
Isilon IP was mounted. After many hours of troubleshooting, we found
the group was newly created and different than our old groups.
The group had an attribute we are not yet familiar with:
ipaNTSecurityIdentifier
The group also had an objectClass none of our others have: ipaNTGroupAttrs
This brought to my attention an issue I saw last week when trying to
add an IPA replica to our cluster. This is new prompting that I have
not seen before while setting up replicas:
WARNING: 1755 existing users or groups do not have a SID identifier
assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1)
man page
for details.
Do you want to run the ipa-sidgen task? [no]:
----
I'm trying to understand the thread "Login failed due to an unknown
reason"
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
where Alexander explains how to fix SIDs. Also there is a thread: IPA
WebGUI login fails with "Login failed due to an unknown reason".
Are SIDs now required? An aside, in one of my install-replica
attempts last week I was asked to provide a NetBIOS name. :(
This is part of the Kerberos hardening in the wake of recent Active
Directory CVEs. Microsoft and Samba team recently (November 2021)
changed the logic to force Kerberos tickets to have PAC records or be
rejected. FreeIPA implements an AD-like environment and is now doing the
same. We don't yet reject PACless Kerberos tickets from IPA
users/services but we do reject them over trusted connections (like AD)
for last five years, so this is already present but not as a default.
With November 2021 Microsoft and Samba team security updates it becomes
a default.
Some information what is it about can be found in the IPA ticket
https://pagure.io/freeipa/issue/8995 and in a design page
https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html.
There are more details forthcoming if I ever complete my blog post.
SIDs are now assigned to IPA users/groups in default installation.
IPA KDC already knows that when domain SID is configured in IPA
deployment and SID is available in a Kebreros principal entry in LDAP,
then MS-PAC record structure should be added to the Kerberos ticket to
be issued. This is particulary required for trust to Active Directory as
there are no other ways to guarantee a Kerberos principal represents
what it claims to represent. PAC structure contains details that allow
to tie name-based Kerberos principal to underlying operating system
identity as a part of authorization process. In Active Directory this is
not entirely needed because AD doesn't really deal with name-based
authorization and instead relies on SIDs of the users/groups for both
identity mapping and access controls.
Samba, effectively, forces now to have PAC record in Kerberos ticket if
you are operating in Active Directory-like environment (domain member or
domain controller). If you are using Kerberos to authenticate, Samba
will reject any Kerberos ticket that does not have a consistent PAC record.
For existing deployments, when IPA is upgraded to the version that
implements the Kerberos hardening, we do not automatically add missing
SIDs to users and groups. Generating SIDs in case of large deployments
might take some time and administrators might want to schedule that to
happen at some hidden replica and at some off-work time, ideally. Also,
ID range needs to be able to handle these assignments, it is not always
possible to adjust them automatically. KDC now provides more logging
around conflicting cases as well, as can be seen in krb5kdc.
My IPA cluster is now wanting to do these SMB/AD sorts of things.
Newly created groups now have ipaNTSecurityIdentifier, which causes
permission issues when mounting NFS on our Isilon. Are we forced down
this road or do I have something misconfigured that is "half-way"
doing AD? I'd like to learn about the big picture.
You need to give more details about what you actually see. There should
be no effect on NFS mounting other than your Kerberos tickets become
larger if Isilon NFS Kerberos support is unaware of PAC processing. If
you see something specific in your krb5kdc.log, please show those
entries. I suspect that Isilon is not really up to date with these
Kerberos hardening enhancements as they weren't really participating in
the work we've been doing together with Microsoft to close done the
issues which became public November 2021 (it took about a year to get
through all this mess).
If Isilon NFS Kerberos implementation is capable to take and parse PAC
record to recover group membership information as recorded by KDC, then
it might be using that information to decide whether a Kerberos
principal is allowed to access some resources. Then missing SIDs in the
group objects will make those groups' not present in the user's PAC
entry (PAC contains relative IDs (RIDs) of groups from the same domain
that user is a member of). However, I am not familiar with internals of
Isilon to say whether this really happening and without additional logs
it is hard to say what your problem really is.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
9:01 a.m.
New subject: Group permissions failing on group with ipaNTSecurityIdentifier attribute
On 2/1/22 09:24, Scott Serr via FreeIPA-users wrote:
Hello,
I have an IPA cluster of 5 servers, running version 4.9.6-10. The
system was put in production Feb 2021 and has been updated several
times. These updates have sometimes not gone well:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
I'll try to keep this concise. A user was not able to access an NFS
share provided by our EMC Isilon. They were a member of the group
that owned the directory/share. But not always, it depended upon what
Isilon IP was mounted. After many hours of troubleshooting, we found
the group was newly created and different than our old groups.
The group had an attribute we are not yet familiar with:
ipaNTSecurityIdentifier
The group also had an objectClass none of our others have:
ipaNTGroupAttrs
This brought to my attention an issue I saw last week when trying to
add an IPA replica to our cluster. This is new prompting that I have
not seen before while setting up replicas:
WARNING: 1755 existing users or groups do not have a SID identifier
assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin
generate
the SID identifier for all these users. Please note, in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1)
man page
for details.
Do you want to run the ipa-sidgen task? [no]:
----
I'm trying to understand the thread "Login failed due to an unknown
reason"
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
where Alexander explains how to fix SIDs. Also there is a thread: IPA
WebGUI login fails with "Login failed due to an unknown reason".
Are SIDs now required? An aside, in one of my install-replica
attempts last week I was asked to provide a NetBIOS name. :(
My IPA cluster is now wanting to do these SMB/AD sorts of things.
Newly created groups now have ipaNTSecurityIdentifier, which causes
permission issues when mounting NFS on our Isilon. Are we forced down
this road or do I have something misconfigured that is "half-way"
doing AD? I'd like to learn about the big picture.
Alexander asked in the "Login failed do to an unknown reason" thread if
ipa migrate-ds was run from another IPA instance. It was and seems to
have caused these sorts of problems. In my case I ran migrate-ds from
OpenLDAP. Would this be causing my SID issues? I may need to setup a
test environment and run "ipa-sidgen" and see if it behaves. I'm
apprehensive of doing it in production, as it really confused Isilon NFS
mount permission.
Thank you for any guidance,
Scott
9:24 a.m.
New subject: Group permissions failing on group with ipaNTSecurityIdentifier attribute
On ke, 02 helmi 2022, Scott Serr via FreeIPA-users wrote:
On 2/1/22 09:24, Scott Serr via FreeIPA-users wrote:
>Hello,
>
>I have an IPA cluster of 5 servers, running version 4.9.6-10. The
>system was put in production Feb 2021 and has been updated several
>times. These updates have sometimes not gone well:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
>I'll try to keep this concise. A user was not able to access an NFS
>share provided by our EMC Isilon. They were a member of the group
>that owned the directory/share. But not always, it depended upon
>what Isilon IP was mounted. After many hours of troubleshooting, we
>found the group was newly created and different than our old groups.
>
>The group had an attribute we are not yet familiar with:
>ipaNTSecurityIdentifier
>The group also had an objectClass none of our others have:
>ipaNTGroupAttrs
>
>This brought to my attention an issue I saw last week when trying to
>add an IPA replica to our cluster. This is new prompting that I
>have not seen before while setting up replicas:
>
>WARNING: 1755 existing users or groups do not have a SID identifier
>assigned.
>Installer can run a task to have ipa-sidgen Directory Server plugin
>generate
>the SID identifier for all these users. Please note, in case of a high
>number of users and groups, the operation might lead to high replication
>traffic and performance degradation. Refer to ipa-adtrust-install(1)
>man page
>for details.
>
>Do you want to run the ipa-sidgen task? [no]:
>
>----
>
>I'm trying to understand the thread "Login failed due to an unknown
>reason"
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>where Alexander explains how to fix SIDs. Also there is a thread:
>IPA WebGUI login fails with "Login failed due to an unknown reason".
>
>Are SIDs now required? An aside, in one of my install-replica
>attempts last week I was asked to provide a NetBIOS name. :(
>
>My IPA cluster is now wanting to do these SMB/AD sorts of things.
>Newly created groups now have ipaNTSecurityIdentifier, which causes
>permission issues when mounting NFS on our Isilon. Are we forced
>down this road or do I have something misconfigured that is
>"half-way" doing AD? I'd like to learn about the big picture.
Alexander asked in the "Login failed do to an unknown reason" thread
if ipa migrate-ds was run from another IPA instance. It was and seems
to have caused these sorts of problems. In my case I ran migrate-ds
from OpenLDAP. Would this be causing my SID issues? I may need to
setup a test environment and run "ipa-sidgen" and see if it behaves.
I'm apprehensive of doing it in production, as it really confused
Isilon NFS mount permission.
ipa migrate-ds from non-IPA LDAP would not be affected as it would not
(most likely) have IPA-specific schema for SIDs.
As I said in my response to you yesterday, please provide more specific
details how exactly Isilon NFS is misbehaving.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
839
days inactive
840
days old
freeipa-users@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
Alexander Bokovoy -
Scott Serr