from:"Ronald Wimmer via FreeIPA\-users"

[Freeipa-users] Re: Create IPA user via LDAP

2024-02-13 Thread Ronald Wimmer via FreeIPA-users


On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:

On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:

On 13.02.24 17:47, Rob Crittenden wrote:


I don't think it's possible to speculate without knowing your process.

This requires the cleartext password so assuming you create the staged
user then immediately active them, that would be the time to do the
bind. Otherwise you have to store cleartext passwords and that is a
recipe for disaster.


User is created by an external tool. User activation in IPA is done by 
a script on one of the IPA servers periodically. Sadly, the external 
tool cannot do an initial LDAP bind in order to create a users's krb 
LDAP attributes. I am looking for a simple way these properties are 
created.


Sure I could say a user has to SSH somewhere but why can't that happen 
if a user tries to login to IPA's WebGUI and the krb properties are 
missing? Or is there another option for users to accomplish this?


Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the 
hood. It allows the WebUI to talk to the LDAP server on behalf of the 
user. This feature require a proper Kerberos credentials. See 
https://www.freeipa.org/page/V4/Service_Constraint_Delegation


I already mentioned the recommended option to archive this a while ago. 
You may have missed the piece of information in this very long thread. 
IPA servers have a special /ipa/migration route (e.g. 
https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. 
Under the hood the endpoint just does an LDAP bind with username and 
password. You can ask your users to either log into a machine with ssh 
or go to the migration page.


I did indeed miss that vital information. It is more than sufficient for 
our needs.


Thanks a lot guys. All scenarios that need to be working in our 
environment do actually work now.


Cheers,
Ronald
--
___
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: Create IPA user via LDAP

2024-02-13 Thread Ronald Wimmer via FreeIPA-users


On 13.02.24 17:47, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 13.02.24 07:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:

On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:

Remark: If I set a new password for this particular user
after the user has been activated, it works.


We are still facing this particular problem and do not have
any clue why the initial password set by the external system
does not work. Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format?
389-DS expects hashed passwords in a specific format, e.g.
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and
100,000 iterations.

IPA cannot create Kerberos keys from a pre-hashed passwords.
Kerberos does not work until the user's Kerberos key is
generated from a plain password, e.g. with a password change at
https://yourserver/ipa/migration/. SSSD can also detect the
case and generate Kerberos keys.

When you log into LDAP as "cn=Directory Manager", then you can
read and check the "userPassword" and "krbPrincipalKey"
entries.

Christian


We are providing plaintext passwords. When the user is initially
created in the staging area the password does not seem to work.
When the user is activated and thus moved to the right place in
the LDAP tree we can set a different password that works
immediately.

In both cases an LDAP browser reveals that the password gets
hashed immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first
test --last user testuser

This creates a staging user, sets their password to "MyPass1234",
and marks the password as expired. IPA always marks passwords as
expired when they are touched by a different user. They are ways
to work around the limitation (passSyncManagersDNs / PassSync
Service)

$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the reset
their password.

By the way, you do not need migration mode if you are providing
cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I should
run into the same issue when modifying a user's password (over
LDAP) later on.

Maybe Flo, Rob or Alexander could clarify what to expect in which
scenario and how to disable immediate expiration if necessary?


The password expiration is controlled by ipa_pwd_extop plugin. To
disable password expiration, add the user DN of your service
account to the "passSyncManagersDNs" attribute of
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the
setting to all your servers manually.


I found out that the password is working perfectly fine when ssh-ing
to an IPA machine. Also su works. But trying to logon to the WebUI
does not. I do get "The password or username you entered is
incorrect". Might be related to the fact that the user does not have
any kerberos specific LDAP attributes(apart from krbCanonicalName
and krbPrincipalName) after initial creation from the external
system.

As the password is set in plaintext from the external system there
should be a possibility for IPA to generate Kerberos keys etc. What
could I try?


It looks like IPA generates missing attributes after some time. When
I tried to login to the WebUI just seconds ago it worked. Can the
generation of missing attributes be triggered manually?


It is triggered as you move the user from staging. The operation is
asynchronous so might take place shortly after the move. There is no
specific way to control it, sorry


What I see is that no LDAP attributes were added after having moved the
user from staging. Even after minutes. When I use this particular user
for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and
krbPrincipalKey are added almost immediately.
--


This is SSSD "migrating" the password. If migration mode is enabled and
SSSD can't get a Kerberos ticket it will do an LDAP bind instead which
will cause the Kerberos keys to be generated.

The WebUI only uses Kerberos. You'd have to use the password migration
page to set the keys.


Perfect. I can confirm that all required LDAP properties appear after
I do an LDAP bind manually.


What would probably be the best way to do this in an automated way? What
would you suggest?


I don't think it's possible to speculate

[Freeipa-users] Re: Create IPA user via LDAP

2024-02-13 Thread Ronald Wimmer via FreeIPA-users


On 13.02.24 07:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:

On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:

Remark: If I set a new password for this particular user
after the user has been activated, it works.


We are still facing this particular problem and do not have
any clue why the initial password set by the external system
does not work. Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format?
389-DS expects hashed passwords in a specific format, e.g.
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and
100,000 iterations.

IPA cannot create Kerberos keys from a pre-hashed passwords.
Kerberos does not work until the user's Kerberos key is
generated from a plain password, e.g. with a password change at
https://yourserver/ipa/migration/. SSSD can also detect the
case and generate Kerberos keys.

When you log into LDAP as "cn=Directory Manager", then you can
read and check the "userPassword" and "krbPrincipalKey" entries.

Christian


We are providing plaintext passwords. When the user is initially
created in the staging area the password does not seem to work.
When the user is activated and thus moved to the right place in
the LDAP tree we can set a different password that works
immediately.

In both cases an LDAP browser reveals that the password gets
hashed immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first
test --last user testuser

This creates a staging user, sets their password to "MyPass1234",
and marks the password as expired. IPA always marks passwords as
expired when they are touched by a different user. They are ways
to work around the limitation (passSyncManagersDNs / PassSync
Service)

$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the reset
their password.

By the way, you do not need migration mode if you are providing
cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I should
run into the same issue when modifying a user's password (over
LDAP) later on.

Maybe Flo, Rob or Alexander could clarify what to expect in which
scenario and how to disable immediate expiration if necessary?


The password expiration is controlled by ipa_pwd_extop plugin. To
disable password expiration, add the user DN of your service
account to the "passSyncManagersDNs" attribute of
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the
setting to all your servers manually.


I found out that the password is working perfectly fine when ssh-ing
to an IPA machine. Also su works. But trying to logon to the WebUI
does not. I do get "The password or username you entered is
incorrect". Might be related to the fact that the user does not have
any kerberos specific LDAP attributes(apart from krbCanonicalName
and krbPrincipalName) after initial creation from the external 
system.


As the password is set in plaintext from the external system there
should be a possibility for IPA to generate Kerberos keys etc. What
could I try?


It looks like IPA generates missing attributes after some time. When
I tried to login to the WebUI just seconds ago it worked. Can the
generation of missing attributes be triggered manually?


It is triggered as you move the user from staging. The operation is
asynchronous so might take place shortly after the move. There is no
specific way to control it, sorry


What I see is that no LDAP attributes were added after having moved the
user from staging. Even after minutes. When I use this particular user
for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and
krbPrincipalKey are added almost immediately.
--


This is SSSD "migrating" the password. If migration mode is enabled and
SSSD can't get a Kerberos ticket it will do an LDAP bind instead which
will cause the Kerberos keys to be generated.

The WebUI only uses Kerberos. You'd have to use the password migration
page to set the keys.


Perfect. I can confirm that all required LDAP properties appear after I 
do an LDAP bind manually.


What would probably be the best way to do this in an automated way? What 
would you suggest?

--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.

[Freeipa-users] Re: Create IPA user via LDAP

2024-02-12 Thread Ronald Wimmer via FreeIPA-users


On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:

On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:

Remark: If I set a new password for this particular user
after the user has been activated, it works.


We are still facing this particular problem and do not have
any clue why the initial password set by the external system
does not work. Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format?
389-DS expects hashed passwords in a specific format, e.g.
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and
100,000 iterations.

IPA cannot create Kerberos keys from a pre-hashed passwords.
Kerberos does not work until the user's Kerberos key is
generated from a plain password, e.g. with a password change at
https://yourserver/ipa/migration/. SSSD can also detect the
case and generate Kerberos keys.

When you log into LDAP as "cn=Directory Manager", then you can
read and check the "userPassword" and "krbPrincipalKey" entries.

Christian


We are providing plaintext passwords. When the user is initially
created in the staging area the password does not seem to work.
When the user is activated and thus moved to the right place in
the LDAP tree we can set a different password that works
immediately.

In both cases an LDAP browser reveals that the password gets
hashed immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first
test --last user testuser

This creates a staging user, sets their password to "MyPass1234",
and marks the password as expired. IPA always marks passwords as
expired when they are touched by a different user. They are ways
to work around the limitation (passSyncManagersDNs / PassSync
Service)

$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the reset
their password.

By the way, you do not need migration mode if you are providing
cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I should
run into the same issue when modifying a user's password (over
LDAP) later on.

Maybe Flo, Rob or Alexander could clarify what to expect in which
scenario and how to disable immediate expiration if necessary?


The password expiration is controlled by ipa_pwd_extop plugin. To
disable password expiration, add the user DN of your service
account to the "passSyncManagersDNs" attribute of
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the
setting to all your servers manually.


I found out that the password is working perfectly fine when ssh-ing
to an IPA machine. Also su works. But trying to logon to the WebUI
does not. I do get "The password or username you entered is
incorrect". Might be related to the fact that the user does not have
any kerberos specific LDAP attributes(apart from krbCanonicalName
and krbPrincipalName) after initial creation from the external system.

As the password is set in plaintext from the external system there
should be a possibility for IPA to generate Kerberos keys etc. What
could I try?


It looks like IPA generates missing attributes after some time. When
I tried to login to the WebUI just seconds ago it worked. Can the
generation of missing attributes be triggered manually?


It is triggered as you move the user from staging. The operation is
asynchronous so might take place shortly after the move. There is no
specific way to control it, sorry


What I see is that no LDAP attributes were added after having moved the
user from staging. Even after minutes. When I use this particular user
for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and
krbPrincipalKey are added almost immediately.
--


This is SSSD "migrating" the password. If migration mode is enabled and
SSSD can't get a Kerberos ticket it will do an LDAP bind instead which
will cause the Kerberos keys to be generated.

The WebUI only uses Kerberos. You'd have to use the password migration
page to set the keys.


Perfect. I can confirm that all required LDAP properties appear after I 
do an LDAP bind manually.


Cheers,
Ronald
--
___
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/projec

[Freeipa-users] Re: Create IPA user via LDAP

2024-02-12 Thread Ronald Wimmer via FreeIPA-users


On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:

On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after 
the user has been activated, it works.


We are still facing this particular problem and do not have any 
clue why the initial password set by the external system does 
not work. Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format? 
389-DS expects hashed passwords in a specific format, e.g. 
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and 
100,000 iterations.


IPA cannot create Kerberos keys from a pre-hashed passwords. 
Kerberos does not work until the user's Kerberos key is 
generated from a plain password, e.g. with a password change at 
https://yourserver/ipa/migration/. SSSD can also detect the case 
and generate Kerberos keys.


When you log into LDAP as "cn=Directory Manager", then you can 
read and check the "userPassword" and "krbPrincipalKey" entries.


Christian


We are providing plaintext passwords. When the user is initially 
created in the staging area the password does not seem to work. 
When the user is activated and thus moved to the right place in 
the LDAP tree we can set a different password that works 
immediately.


In both cases an LDAP browser reveals that the password gets 
hashed immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first 
test --last user testuser


This creates a staging user, sets their password to "MyPass1234", 
and marks the password as expired. IPA always marks passwords as 
expired when they are touched by a different user. They are ways 
to work around the limitation (passSyncManagersDNs / PassSync 
Service)


$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the reset 
their password.


By the way, you do not need migration mode if you are providing 
cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I should 
run into the same issue when modifying a user's password (over 
LDAP) later on.


Maybe Flo, Rob or Alexander could clarify what to expect in which 
scenario and how to disable immediate expiration if necessary?


The password expiration is controlled by ipa_pwd_extop plugin. To 
disable password expiration, add the user DN of your service account 
to the "passSyncManagersDNs" attribute of 
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting 
to all your servers manually.


I found out that the password is working perfectly fine when ssh-ing 
to an IPA machine. Also su works. But trying to logon to the WebUI 
does not. I do get "The password or username you entered is 
incorrect". Might be related to the fact that the user does not have 
any kerberos specific LDAP attributes(apart from krbCanonicalName and 
krbPrincipalName) after initial creation from the external system.


As the password is set in plaintext from the external system there 
should be a possibility for IPA to generate Kerberos keys etc. What 
could I try?


It looks like IPA generates missing attributes after some time. When I 
tried to login to the WebUI just seconds ago it worked. Can the 
generation of missing attributes be triggered manually?


It is triggered as you move the user from staging. The operation is
asynchronous so might take place shortly after the move. There is no
specific way to control it, sorry


What I see is that no LDAP attributes were added after having moved the 
user from staging. Even after minutes. When I use this particular user 
for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and 
krbPrincipalKey are added almost immediately.

--
___
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: Create IPA user via LDAP

2024-02-12 Thread Ronald Wimmer via FreeIPA-users


On 12.02.24 14:36, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 14.15, Christian Heimes wrote:

While writing the lines above another question came up in my mind:
Is there a way to forbid password modification for IPA users so that 
users are forced to do that in an external sytem?


Yes, that's easy, remove the self service permission "Self can write 
own password".


Actually, it's not *that* trivial. Alexander just pointed out to me, 
that this will break service and host accounts requesting their own 
keytab. Ops!


You may be able to archive the desired effect by replacing the ACI with 
a different self-service ACI that permits self-write for everybody 
except externally managed user accounts. Perhaps you can add your 
external users to a non-POSIX group and add a filter like


  (targetfilter = 
"(memberOf!=cn=external-passwords,cn=groups,cn=accounts,$SUFFIX)")


to the self-service ACI.


That's a great idea. Thanks for 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Create IPA user via LDAP

2024-02-12 Thread Ronald Wimmer via FreeIPA-users


On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after 
the user has been activated, it works.


We are still facing this particular problem and do not have any 
clue why the initial password set by the external system does not 
work. Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format? 
389-DS expects hashed passwords in a specific format, e.g. 
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and 
100,000 iterations.


IPA cannot create Kerberos keys from a pre-hashed passwords. 
Kerberos does not work until the user's Kerberos key is generated 
from a plain password, e.g. with a password change at 
https://yourserver/ipa/migration/. SSSD can also detect the case 
and generate Kerberos keys.


When you log into LDAP as "cn=Directory Manager", then you can 
read and check the "userPassword" and "krbPrincipalKey" entries.


Christian


We are providing plaintext passwords. When the user is initially 
created in the staging area the password does not seem to work. 
When the user is activated and thus moved to the right place in the 
LDAP tree we can set a different password that works immediately.


In both cases an LDAP browser reveals that the password gets hashed 
immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test 
--last user testuser


This creates a staging user, sets their password to "MyPass1234", 
and marks the password as expired. IPA always marks passwords as 
expired when they are touched by a different user. They are ways to 
work around the limitation (passSyncManagersDNs / PassSync Service)


$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the reset 
their password.


By the way, you do not need migration mode if you are providing 
cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I should 
run into the same issue when modifying a user's password (over LDAP) 
later on.


Maybe Flo, Rob or Alexander could clarify what to expect in which 
scenario and how to disable immediate expiration if necessary?


The password expiration is controlled by ipa_pwd_extop plugin. To 
disable password expiration, add the user DN of your service account 
to the "passSyncManagersDNs" attribute of 
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting 
to all your servers manually.


I found out that the password is working perfectly fine when ssh-ing to 
an IPA machine. Also su works. But trying to logon to the WebUI does 
not. I do get "The password or username you entered is incorrect". Might 
be related to the fact that the user does not have any kerberos specific 
LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after 
initial creation from the external system.


As the password is set in plaintext from the external system there 
should be a possibility for IPA to generate Kerberos keys etc. What 
could I try?


It looks like IPA generates missing attributes after some time. When I 
tried to login to the WebUI just seconds ago it worked. Can the 
generation of missing attributes be triggered manually?

--
___
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: Create IPA user via LDAP

2024-02-12 Thread Ronald Wimmer via FreeIPA-users


On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after 
the user has been activated, it works.


We are still facing this particular problem and do not have any 
clue why the initial password set by the external system does not 
work. Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format? 
389-DS expects hashed passwords in a specific format, e.g. 
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and 
100,000 iterations.


IPA cannot create Kerberos keys from a pre-hashed passwords. 
Kerberos does not work until the user's Kerberos key is generated 
from a plain password, e.g. with a password change at 
https://yourserver/ipa/migration/. SSSD can also detect the case 
and generate Kerberos keys.


When you log into LDAP as "cn=Directory Manager", then you can read 
and check the "userPassword" and "krbPrincipalKey" entries.


Christian


We are providing plaintext passwords. When the user is initially 
created in the staging area the password does not seem to work. When 
the user is activated and thus moved to the right place in the LDAP 
tree we can set a different password that works immediately.


In both cases an LDAP browser reveals that the password gets hashed 
immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test 
--last user testuser


This creates a staging user, sets their password to "MyPass1234", and 
marks the password as expired. IPA always marks passwords as expired 
when they are touched by a different user. They are ways to work 
around the limitation (passSyncManagersDNs / PassSync Service)


$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the reset their 
password.


By the way, you do not need migration mode if you are providing 
cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I should run 
into the same issue when modifying a user's password (over LDAP) later 
on.


Maybe Flo, Rob or Alexander could clarify what to expect in which 
scenario and how to disable immediate expiration if necessary?


The password expiration is controlled by ipa_pwd_extop plugin. To 
disable password expiration, add the user DN of your service account to 
the "passSyncManagersDNs" attribute of 
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to 
all your servers manually.


I found out that the password is working perfectly fine when ssh-ing to 
an IPA machine. Also su works. But trying to logon to the WebUI does 
not. I do get "The password or username you entered is incorrect". Might 
be related to the fact that the user does not have any kerberos specific 
LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after 
initial creation from the external system.


As the password is set in plaintext from the external system there 
should be a possibility for IPA to generate Kerberos keys etc. What 
could I try?



--
___
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: Create IPA user via LDAP

2024-02-12 Thread Ronald Wimmer via FreeIPA-users


On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the 
user has been activated, it works.


We are still facing this particular problem and do not have any clue 
why the initial password set by the external system does not work. 
Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format? 389-DS 
expects hashed passwords in a specific format, e.g. 
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and 
100,000 iterations.


IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos 
does not work until the user's Kerberos key is generated from a plain 
password, e.g. with a password change at 
https://yourserver/ipa/migration/. SSSD can also detect the case and 
generate Kerberos keys.


When you log into LDAP as "cn=Directory Manager", then you can read 
and check the "userPassword" and "krbPrincipalKey" entries.


Christian


We are providing plaintext passwords. When the user is initially 
created in the staging area the password does not seem to work. When 
the user is activated and thus moved to the right place in the LDAP 
tree we can set a different password that works immediately.


In both cases an LDAP browser reveals that the password gets hashed 
immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test 
--last user testuser


This creates a staging user, sets their password to "MyPass1234", and 
marks the password as expired. IPA always marks passwords as expired 
when they are touched by a different user. They are ways to work around 
the limitation (passSyncManagersDNs / PassSync Service)


$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the reset their 
password.


By the way, you do not need migration mode if you are providing 
cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I should run 
into the same issue when modifying a user's password (over LDAP) later on.


Maybe Flo, Rob or Alexander could clarify what to expect in which 
scenario and how to disable immediate expiration if necessary?


While writing the lines above another question came up in my mind:
Is there a way to forbid password modification for IPA users so that 
users are forced to do that in an external sytem?


Cheers,
Ronald
--
___
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: Create IPA user via LDAP

2024-02-12 Thread Ronald Wimmer via FreeIPA-users


On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the 
user has been activated, it works.


We are still facing this particular problem and do not have any clue 
why the initial password set by the external system does not work. Any 
ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct format? 389-DS 
expects hashed passwords in a specific format, e.g. 
"{PBKDF2-SHA512}10$base64data" for PKBDF2 with SHA-512 and 100,000 
iterations.


IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos 
does not work until the user's Kerberos key is generated from a plain 
password, e.g. with a password change at 
https://yourserver/ipa/migration/. SSSD can also detect the case and 
generate Kerberos keys.


When you log into LDAP as "cn=Directory Manager", then you can read and 
check the "userPassword" and "krbPrincipalKey" entries.


Christian


We are providing plaintext passwords. When the user is initially created 
in the staging area the password does not seem to work. When the user is 
activated and thus moved to the right place in the LDAP tree we can set 
a different password that works immediately.


In both cases an LDAP browser reveals that the password gets hashed 
immediately by 389DS. (PBKDF2_SHA256)


Cheers,
Ronald
--
___
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: Create IPA user via LDAP

2024-02-11 Thread Ronald Wimmer via FreeIPA-users

On 02.02.24 09:48, Ronald Wimmer via FreeIPA-users wrote:

On 25.01.24 19:52, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:

On 08.01.24 17:58, Alexander Bokovoy wrote:

On Пан, 08 сту 2024, Ronald Wimmer wrote:

On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:

On 02.01.24 16:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:

In our company we do have an IAM tool for user management. We
need to
create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

As the tool does not support FreeIPA yet they asked if there is
a way
to manage users by using LDAP only. Could that work? What about
attributes like ipaNTSecurityIdentifier, ipaUniqueID or
uidNumber?

Learn about lifecycle management. This is your way of
integrating with
such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper

I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at
ipa-activate-all[836863]:
ipa: ERROR: Constraint violation: pre-hashed passwords are not
valid

I need to set passwords from the external system.

You need to enable migration mode (ipa config-mod
--enable-migration true).

By default a pre-hashed password can only be set once: during the
user
add operation.

Ok. So this would not work for a password change. So if we need to
set an initial password and change that particular password in some
point in time the only feasible way is the IPA API, right?

Can the immediate password expiration be overridden?

As we have an upcoming please allow me to ask if I got the point
here.

I appreciate your support in this matter!

I was looking over the code. The only way to accept pre-hashed
passwords

is when they also have Kerberos keys set. This means you cannot use
external LDAP modify/add for that as you cannot create the Kerberos
key

without knowing a Kerberos master key.

So the only other option is to submit a clear-text password:

userPassword: {CLEAR}text-password

That will be accepted and if bind DN that performed this change is
either a cn=Directory Manager or a one from the passsync managers, it
would also not be marked for expiration immediately.

If I try to set the userPassword attribute to some value with an LDAP
browser and chose "plaintext" the value gets hashed immediately. I do
see {PBKDF2_SHA256}. As a consequence the user cannot be activated.

What am I doing wrong?

I tried to enable migration mode and wanted to try it again but now I
cannot connect to IPA's LDAP directory at all anymore...

[root@tipa01 ~]# ipa config-mod --enable-migration=true
Maximum username length: 32
Maximum hostname length: 64
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: ipatest.mydomain.at
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: True
Certificate Subject base: O=IPATEST.MYDOMAIN.AT
Password Expiration Notification (days): 4
Password plugin features: AllowNThash, KDC:Disable Last Success
SELinux user map order:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023

Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at
IPA master capable of PKINIT: tipa01.ipatest.mydomain.at,
tipa02.ipatest.mydomain.at
IPA CA servers: tipa01.ipatest.mydomain.at
IPA CA renewal master: tipa01.ipatest.mydomain.at
Domain resolution order: org.mydomain.at:ipatest.mydomain.at
[root@tipa01 ~]# ipa config-mod --enable-migration=false
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may
provide more information, Minor (2529638972): KDC returned error
string: PROCESS_TGS

I should have done a little debugging instead of asking again. dirsrv
was not running after ipa config-mod --enable-migration=true

OK. Let me summarize... The whole procedure (creating a user in the
staging area if the password is a cleartext one) works if migration mode
is enabled. What drawbacks arise if migration mode is enabled all the
time?

It is extra work whenever a user is unauthorized and has provided a
password because it will try to authenticate with both Kerberos and LDAP
in an attempt to migrate it.

When I add a new IPA user as described above it ge

[Freeipa-users] Re: Create IPA user via LDAP

2024-02-02 Thread Ronald Wimmer via FreeIPA-users

On 25.01.24 19:52, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:

On 08.01.24 17:58, Alexander Bokovoy wrote:

On Пан, 08 сту 2024, Ronald Wimmer wrote:

On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:

On 02.01.24 16:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:

In our company we do have an IAM tool for user management. We
need to
create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
ipa: ERROR: Constraint violation: pre-hashed passwords are not valid

I need to set passwords from the external system.

You need to enable migration mode (ipa config-mod
--enable-migration true).

By default a pre-hashed password can only be set once: during the
user
add operation.

Ok. So this would not work for a password change. So if we need to
set an initial password and change that particular password in some
point in time the only feasible way is the IPA API, right?

Can the immediate password expiration be overridden?

As we have an upcoming please allow me to ask if I got the point here.

I appreciate your support in this matter!

I was looking over the code. The only way to accept pre-hashed passwords
is when they also have Kerberos keys set. This means you cannot use
external LDAP modify/add for that as you cannot create the Kerberos key
without knowing a Kerberos master key.

So the only other option is to submit a clear-text password:

userPassword: {CLEAR}text-password

That will be accepted and if bind DN that performed this change is
either a cn=Directory Manager or a one from the passsync managers, it
would also not be marked for expiration immediately.

What am I doing wrong?

I tried to enable migration mode and wanted to try it again but now I
cannot connect to IPA's LDAP directory at all anymore...

I should have done a little debugging instead of asking again. dirsrv
was not running after ipa config-mod --enable-migration=true

It is extra work whenever a user is unauthorized and has provided a
password because it will try to authenticate with both Kerberos and LDAP
in an attempt to migrate it.

When I add a new IPA user as described above it gets created in the
staging area and automaticalle moved to the correc

[Freeipa-users] Re: Enable/Disable an IPA user via LDAP

2024-02-01 Thread Ronald Wimmer via FreeIPA-users


On 01.02.24 19:29, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

Is it possible? If yes what needs to be done?


Set nsaccountlock to TRUE/FALSE. This is an operational attribute so
when searching for it you have to specify it as an attribute you want to
see with ldapsearch.


Perfect! Thanks a lot!
--
___
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] Enable/Disable an IPA user via LDAP

2024-02-01 Thread Ronald Wimmer via FreeIPA-users


Is it possible? If yes what needs to be done?

Cheers,
Ronald
--
___
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: Create IPA user via LDAP

2024-01-25 Thread Ronald Wimmer via FreeIPA-users

On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:

On 08.01.24 17:58, Alexander Bokovoy wrote:

On Пан, 08 сту 2024, Ronald Wimmer wrote:

On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:

On 02.01.24 16:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
In our company we do have an IAM tool for user management. We
need to

create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

As the tool does not support FreeIPA yet they asked if there is
a way

to manage users by using LDAP only. Could that work? What about
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?

Learn about lifecycle management. This is your way of integrating
with

such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper

I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
ipa: ERROR: Constraint violation: pre-hashed passwords are not valid

I need to set passwords from the external system.

You need to enable migration mode (ipa config-mod
--enable-migration true).

By default a pre-hashed password can only be set once: during the user
add operation.

Ok. So this would not work for a password change. So if we need to
set an initial password and change that particular password in some
point in time the only feasible way is the IPA API, right?

Can the immediate password expiration be overridden?

As we have an upcoming please allow me to ask if I got the point here.

I appreciate your support in this matter!

So the only other option is to submit a clear-text password:

userPassword: {CLEAR}text-password

That will be accepted and if bind DN that performed this change is
either a cn=Directory Manager or a one from the passsync managers, it
would also not be marked for expiration immediately.

What am I doing wrong?

I tried to enable migration mode and wanted to try it again but now I
cannot connect to IPA's LDAP directory at all anymore...

IPA CA servers: tipa01.ipatest.mydomain.at
IPA CA renewal master: tipa01.ipatest.mydomain.at
Domain resolution order: org.mydomain.at:ipatest.mydomain.at
[root@tipa01 ~]# ipa config-mod --enable-migration=false
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may
provide more information, Minor (2529638972): KDC returned error string:
PROCESS_TGS

I should have done a little debugging instead of asking again. dirsrv
was not running after ipa config-mod --enable-migration=true

[Freeipa-users] Re: Create IPA user via LDAP

2024-01-25 Thread Ronald Wimmer via FreeIPA-users


On 08.01.24 17:58, Alexander Bokovoy wrote:

On Пан, 08 сту 2024, Ronald Wimmer wrote:

On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:

On 02.01.24 16:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:



On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
In our company we do have an IAM tool for user management. We 
need to

create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

As the tool does not support FreeIPA yet they asked if there is a 
way

to manage users by using LDAP only. Could that work? What about
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?


Learn about lifecycle management. This is your way of integrating 
with

such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper



I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
ipa: ERROR: Constraint violation: pre-hashed passwords are not valid

I need to set passwords from the external system.


You need to enable migration mode (ipa config-mod --enable-migration 
true).


By default a pre-hashed password can only be set once: during the user
add operation.


Ok. So this would not work for a password change. So if we need to 
set an initial password and change that particular password in some 
point in time the only feasible way is the IPA API, right?


Can the immediate password expiration be overridden?


As we have an upcoming please allow me to ask if I got the point here.

I appreciate your support in this matter!



I was looking over the code. The only way to accept pre-hashed passwords
is when they also have Kerberos keys set. This means you cannot use
external LDAP modify/add for that as you cannot create the Kerberos key
without knowing a Kerberos master key.

So the only other option is to submit a clear-text password:

  userPassword: {CLEAR}text-password

That will be accepted and if bind DN that performed this change is
either a cn=Directory Manager or a one from the passsync managers, it
would also not be marked for expiration immediately.



If I try to set the userPassword attribute to some value with an LDAP 
browser and chose "plaintext"  the value gets hashed immediately. I do 
see {PBKDF2_SHA256}. As a consequence the user cannot be activated.


What am I doing wrong?

I tried to enable migration mode and wanted to try it again but now I 
cannot connect to IPA's LDAP directory at all anymore...


[root@tipa01 ~]# ipa config-mod --enable-migration=true
  Maximum username length: 32
  Maximum hostname length: 64
  Home directory base: /home
  Default shell: /bin/sh
  Default users group: ipausers
  Default e-mail domain: ipatest.mydomain.at
  Search time limit: 2
  Search size limit: 100
  User search fields: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Enable migration mode: True
  Certificate Subject base: O=IPATEST.MYDOMAIN.AT
  Password Expiration Notification (days): 4
  Password plugin features: AllowNThash, KDC:Disable Last Success
  SELinux user map order: 
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023

  Default SELinux user: unconfined_u:s0-s0:c0.c1023
  Default PAC types: MS-PAC, nfs:NONE
  IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at
  IPA master capable of PKINIT: tipa01.ipatest.mydomain.at, 
tipa02.ipatest.mydomain.at

  IPA CA servers: tipa01.ipatest.mydomain.at
  IPA CA renewal master: tipa01.ipatest.mydomain.at
  Domain resolution order: org.mydomain.at:ipatest.mydomain.at
[root@tipa01 ~]# ipa config-mod --enable-migration=false
ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may 
provide more information, Minor (2529638972): KDC returned error string: 
PROCESS_TGS

--
___
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: Is it possible to install FreeIPA on different disk than ('/')

2024-01-24 Thread Ronald Wimmer via FreeIPA-users


On 24.01.24 15:35, Finn Fysj via FreeIPA-users wrote:

Currently our installation of FreeIPA is done on root ('/').
Is it possible to install FreeIPA on different disk & mount path wihtout 
causing too much issues?


FreeIPA consists of several components (389DS, Apache, Dogtag, Samba, 
DNS, ...). I seriously doubt that it would be a good idea to move all of 
these components to non-standard paths.


Cheers,
Ronald
--
___
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: Create IPA user via LDAP

2024-01-18 Thread Ronald Wimmer via FreeIPA-users

On 08.01.24 17:58, Alexander Bokovoy wrote:

On Пан, 08 сту 2024, Ronald Wimmer wrote:

On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:

On 02.01.24 16:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
In our company we do have an IAM tool for user management. We
need to

create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

As the tool does not support FreeIPA yet they asked if there is a
way

to manage users by using LDAP only. Could that work? What about
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?

Learn about lifecycle management. This is your way of integrating
with

I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
ipa: ERROR: Constraint violation: pre-hashed passwords are not valid

I need to set passwords from the external system.

You need to enable migration mode (ipa config-mod --enable-migration
true).

By default a pre-hashed password can only be set once: during the user
add operation.

Ok. So this would not work for a password change. So if we need to
set an initial password and change that particular password in some
point in time the only feasible way is the IPA API, right?

Can the immediate password expiration be overridden?

As we have an upcoming please allow me to ask if I got the point here.

I appreciate your support in this matter!

So the only other option is to submit a clear-text password:

userPassword: {CLEAR}text-password

That will be accepted and if bind DN that performed this change is
either a cn=Directory Manager or a one from the passsync managers, it
would also not be marked for expiration immediately.

So. Am I right that our options are to use LDAP with a cleartext
passwort or use the IPA API?

--
___
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: Create IPA user via LDAP

2024-01-08 Thread Ronald Wimmer via FreeIPA-users

On 08.01.24 17:14, Rob Crittenden wrote:

Ronald Wimmer wrote:

On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:

On 02.01.24 16:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:

In our company we do have an IAM tool for user management. We need to
create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

As the tool does not support FreeIPA yet they asked if there is a way
to manage users by using LDAP only. Could that work? What about
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?

Learn about lifecycle management. This is your way of integrating with
such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper

I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
ipa: ERROR: Constraint violation: pre-hashed passwords are not valid

I need to set passwords from the external system.

You need to enable migration mode (ipa config-mod --enable-migration
true).

By default a pre-hashed password can only be set once: during the user
add operation.

Ok. So this would not work for a password change. So if we need to set
an initial password and change that particular password in some point
in time the only feasible way is the IPA API, right?

Can the immediate password expiration be overridden?

As we have an upcoming please allow me to ask if I got the point here.

I appreciate your support in this matter!

I'd recommend you look into the winsync documentation in IPA. There is a
setting you can configure to allow a pre-hashed password to be written
without marking it as expired (because this is what winsync does).

If you use Kerberos then users are going to have to migrate their
password every time it changes on the external system.

I quickly skipped over the documentation. winsync-migrate seems to
require AD trust. I did not mention that before but we need to get rid
of all trusts in our domain landscape.

We will need the ability to create and update users from an external
system. Including passwords. So what would probably be the best option here?

Cheers,
Ronald
--
___
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: Create IPA user via LDAP

2024-01-02 Thread Ronald Wimmer via FreeIPA-users

On 02.01.24 16:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:

In our company we do have an IAM tool for user management. We need to
create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

As the tool does not support FreeIPA yet they asked if there is a way
to manage users by using LDAP only. Could that work? What about
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?

Learn about lifecycle management. This is your way of integrating with
such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper

I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
ipa: ERROR: Constraint violation: pre-hashed passwords are not valid

I need to set passwords from the external system.

You need to enable migration mode (ipa config-mod --enable-migration true).

By default a pre-hashed password can only be set once: during the user
add operation.

Ok. So this would not work for a password change. So if we need to set
an initial password and change that particular password in some point in
time the only feasible way is the IPA API, right?

Can the immediate password expiration be overridden?

[Freeipa-users] Re: Create IPA user via LDAP

2023-12-19 Thread Ronald Wimmer via FreeIPA-users


On 19.12.23 09:23, Ronald Wimmer via FreeIPA-users wrote:



On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
In our company we do have an IAM tool for user management. We need to 
create IPA users via this particular tool. I am aware of all IPA 
commands or API calls to create/modify or delete a user.


As the tool does not support FreeIPA yet they asked if there is a way 
to manage users by using LDAP only. Could that work? What about 
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?


Learn about lifecycle management. This is your way of integrating with
such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper


I followed the instructions from the documentation.

How could I possibly overcome

Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]: 
ipa: ERROR: Constraint violation: pre-hashed passwords are not valid


I need to set passwords from the external system.


I've read 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/QTG5VMGIIL7WNCF2VL27B7JUQQ2UDF5T/?sort=date


So I guess our only chance is to use the IPA API for managing a user 
including its password?


Cheers,
Ronald
--
___
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: Create IPA user via LDAP

2023-12-15 Thread Ronald Wimmer via FreeIPA-users

On 14.12.23 23:31, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.12.23 14:42, Alexander Bokovoy via FreeIPA-users wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:

In our company we do have an IAM tool for user management. We need to
create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.

As the tool does not support FreeIPA yet they asked if there is a way
to manage users by using LDAP only. Could that work? What about
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?

Learn about lifecycle management. This is your way of integrating with
such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper

I took a quick look at the documentation. So... is it right that we have
two options

- use the IPA API or
- LDIF files

Or directly over LDAP.

The external IAM system needs to set a IPA user's password as well. What
would be the way to go here?

[Freeipa-users] Re: Create IPA user via LDAP

2023-12-14 Thread Ronald Wimmer via FreeIPA-users


On 14.12.23 14:42, Alexander Bokovoy via FreeIPA-users wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
In our company we do have an IAM tool for user management. We need to 
create IPA users via this particular tool. I am aware of all IPA 
commands or API calls to create/modify or delete a user.


As the tool does not support FreeIPA yet they asked if there is a way 
to manage users by using LDAP only. Could that work? What about 
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?


Learn about lifecycle management. This is your way of integrating with
such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper



I took a quick look at the documentation. So... is it right that we have 
two options


- use the IPA API or
- LDIF files
--
___
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: Create IPA user via LDAP

2023-12-14 Thread Ronald Wimmer via FreeIPA-users


On 14.12.23 14:42, Alexander Bokovoy wrote:

On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
In our company we do have an IAM tool for user management. We need to 
create IPA users via this particular tool. I am aware of all IPA 
commands or API calls to create/modify or delete a user.


As the tool does not support FreeIPA yet they asked if there is a way 
to manage users by using LDAP only. Could that work? What about 
attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?


Learn about lifecycle management. This is your way of integrating with
such tools bvy creating staged users:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper



Perfect. I wasn't aware that this existed.

Cheers,
Ronald
--
___
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] Create IPA user via LDAP

2023-12-14 Thread Ronald Wimmer via FreeIPA-users

In our company we do have an IAM tool for user management. We need to 
create IPA users via this particular tool. I am aware of all IPA 
commands or API calls to create/modify or delete a user.


As the tool does not support FreeIPA yet they asked if there is a way to 
manage users by using LDAP only. Could that work? What about attributes 
like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?

--
___
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: sudo Problem on AIX

2023-10-13 Thread Ronald Wimmer via FreeIPA-users


On 12.10.23 13:22, Ronald Wimmer via FreeIPA-users wrote:

On 12.10.23 13:06, Ulf Volmer via FreeIPA-users wrote:

On 12.10.23 09:57, Ronald Wimmer via FreeIPA-users wrote:
We do have two users with the same name. One exists locally. The 
other one comes from IPA.


The problem is that the sudo rules also show up for the local user.

I know you do not officially support AIX... but would there probably 
be a solution apart from naming these two users differently?


I don't think, that this can be solved on FreeIPA side.
And also on AIX it is difficult. You can look with lsuser for the 
registry attribute, but I don't know any way to use this in sudo rules.


In general: I would say: try to avoid thos naming conflicts.



I found a solution for that. The problem of this particular IPA user is 
that its sudo rules are permitted on ANY host. I will have to exclude 
the AIX host group.


And here comes my question to the IPA devs... Is it possible to create a 
hostgroup and exclude members of a second hostgroup? (e.g. create a 
hostgroup containing all IPA clients excluding the AIX hostgroup)


Automembership is your friend.
(I would have expected to specify an exclude condition only but that did 
not work.)


Cheers,
Ronald
___
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: sudo Problem on AIX

2023-10-12 Thread Ronald Wimmer via FreeIPA-users


On 12.10.23 13:06, Ulf Volmer via FreeIPA-users wrote:

On 12.10.23 09:57, Ronald Wimmer via FreeIPA-users wrote:
We do have two users with the same name. One exists locally. The other 
one comes from IPA.


The problem is that the sudo rules also show up for the local user.

I know you do not officially support AIX... but would there probably 
be a solution apart from naming these two users differently?


I don't think, that this can be solved on FreeIPA side.
And also on AIX it is difficult. You can look with lsuser for the 
registry attribute, but I don't know any way to use this in sudo rules.


In general: I would say: try to avoid thos naming conflicts.



I found a solution for that. The problem of this particular IPA user is 
that its sudo rules are permitted on ANY host. I will have to exclude 
the AIX host group.


And here comes my question to the IPA devs... Is it possible to create a 
hostgroup and exclude members of a second hostgroup? (e.g. create a 
hostgroup containing all IPA clients excluding the AIX hostgroup)


Cheers,
Ronald
___
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] sudo Problem on AIX

2023-10-12 Thread Ronald Wimmer via FreeIPA-users

We do have two users with the same name. One exists locally. The other 
one comes from IPA.


The problem is that the sudo rules also show up for the local user.

I know you do not officially support AIX... but would there probably be 
a solution apart from naming these two users differently?


Cheers,
Ronald
___
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] Use existing Kerberos ticket for Keycloak Auth

2023-10-06 Thread Ronald Wimmer via FreeIPA-users

I found out that my TGT does not reside in a ticket cache file anymore. 
Instead it is located in a keyring 
(KEYRING:persistent:1073895519:1073895519). How would I fetch this 
ticket with a few lines of python3 code in order to authenticate to 
Keycloak for example?


Cheers,
Ronald
___
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] Which distribution to choose for the enterprise linux desktop

2023-09-15 Thread Ronald Wimmer via FreeIPA-users

If you had to choose between Linux distros which ones are known to work 
very well with FreeIPA? (apart from the obvious like RHEL itself or 
Fedora) Would Ubuntu also be a good choice?


Cheers,
Ronald
___
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: 2FA only for certain hosts/host groups

2023-09-04 Thread Ronald Wimmer via FreeIPA-users


On 30.03.23 11:15, Ronald Wimmer via FreeIPA-users wrote:

On 29.03.23 23:06, Sam Morris via FreeIPA-users wrote:

On 29/03/2023 21:48, Ronald Wimmer via FreeIPA-users wrote:

On 29.03.23 22:30, Ronald Wimmer via FreeIPA-users wrote:
Is it possible to enforce the second factor for a user only when 
trying to login to specific hosts/host groups?


List here says yes... 
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/


I'm gonna give it a try.


Sorry. Clicked on send to early... As I understand the link above, it 
would just be a


ipa host-mod  --auth-ind=otp secure.linuxhost.at

instead of enabling the option for some user. Right?

(or ipa service-mod --auth-ind=otp http/secure.linuxhost.at for a 
certain service)


But when I set the auth indicator on a host it does not seem to work. 
What am I missing?


Get a new TGT without providing a second factor. Then request a 
service ticket for host/secure.linuxhost.at; the KDC should refuse to 
hand out a ticket since your TGT doesn't have the 'otp' authentication 
indicator.


https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html#kerberos-authentication-indicators

See also pam_sss_gss which can used to grant/deny authentication to a 
PAM service based on the authentication indicators present on the 
user's host/$HOSTNAME service ticket:


https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html#enforcing-authentication-indicators

Services that authenticate clients via Kerberos authentication are 
also able to find out which authentication indicators are present on a 
client's service ticket, but I think this is quite new functionality 
that isn't implemented outside of pam_sss_gss so far.


What does this mean for us trying to enable OTP as an additional factor 
on certain hosts? Would I have to configure SSH(d) in a different way?


I would like to revisit this topic. As I did not quit understand the 
answer please let my try to rephrase my initial question:


Is it possible to force a second factor (OTP) for a certain group of 
host when trying to log in via SSH with the same IPA user?


Cheers,
Ronald
___
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] IPA and cron(d)

2023-09-04 Thread Ronald Wimmer via FreeIPA-users


Hi,

we found out that the behavior on our OL9 servers differs from the older 
ones. If a user should be able to use cron on a specific host (service 
in HBAC rule) this works on entry containing the respective user needs to exist in /etc/cron.allow 
on the server itself. Is this the desired behavior?


Cheers,
Ronald
___
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 in Containers - Ready for Prod?

2023-08-17 Thread Ronald Wimmer via FreeIPA-users

We are running it successfully on VMs for several thousand IPA clients.

Am 17. August 2023 11:44:53 MESZ schrieb Jonas R via FreeIPA-users 
:
>Thank you for your fast reply, Ronald!
>
>I guess we'll go for VMs then. 
>___
>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] Re: FreeIPA in Containers - Ready for Prod?

2023-08-17 Thread Ronald Wimmer via FreeIPA-users

As I understood the devs the only option would be an all-in-one container as 
splitting up the components would introduce several challenges that would need 
to be solved. And everything in one container is exactly the opposite what a 
container should be...

So... we do not consider the current container solution as ready for production.

Cheers,
Ronald

Am 17. August 2023 11:20:22 MESZ schrieb Jonas R via FreeIPA-users 
:
>Hello all,
>we have setup a test system with FreeIPA running on a docker (swarm) host and 
>are very happy with the tool. Now we are moving forward towards the planning 
>for implementation and considering wthether to run in in Containers or VMs. 
>
>On the FreeIPA website it says "the team also maintains PoC container release 
>of FreeIPA". That's why I am wondering, if running FreeIPA in containers is 
>generally considered as something for testing environments or PoC, but not for 
>production. Are there any experiences running it in containers for production? 
>Or is everybody using bare metal/VMs? We are planning an environment with 
>40-50 clients on one site. 
>
>Thanks,
>Jonas
>___
>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] Re: In FreeIPA AD trust environment add AD user to local group

2023-07-30 Thread Ronald Wimmer via FreeIPA-users

The referenced thread is about merging local and IPA groups. Not 
explicitly about the direction.


Cheers,
Ronald

On 30.07.23 17:54, Sameer Gurung via FreeIPA-users wrote:
I have followed the link you sent and managed to add users to the local 
docker group when the users are in FreeIPA. However in my case they are 
AD users logging in to linux clients through the IPA AD trust


*Sameer Kr. Gurung*

On Sun, Jul 30, 2023 at 6:07 PM Ronald Wimmer via FreeIPA-users 
<mailto:freeipa-users@lists.fedorahosted.org>> wrote:


Have a look at

https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WR7JQOMWCEXNABNSZGFF2FYN6ENEHEIB/#BBVO35ZP4YFI7C27NASZLYWRWDFY6DRH
 
<https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WR7JQOMWCEXNABNSZGFF2FYN6ENEHEIB/#BBVO35ZP4YFI7C27NASZLYWRWDFY6DRH>


Am 30. Juli 2023 11:17:37 MESZ schrieb Sameer Gurung via
FreeIPA-users mailto:freeipa-users@lists.fedorahosted.org>>:

I have integrated freeipa with AD via a two way trust. However I
now have a problem

How do I add my AD users logging in to linux clients to the
local machines
docker group so that they can run docker.
Any help would be appreciated.
Thanks everyone!

Sameer K Gurung


This message contains confidential information and is intended
only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from
your system. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability
for any errors or omissions in the contents of this message,
which arise as a result of e-mail transmission. If verification
is required please request a hard-copy version.
Saint Mary's College, Shillong, Meghalaya, India-793003,
smcs.ac.in <http://smcs.ac.in>

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org
<mailto:freeipa-users-le...@lists.fedorahosted.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org 
<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
<https://pagure.io/fedora-infrastructure/new_issue>


This message contains confidential information and is intended only for 
the individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. E-mail transmission cannot be 
guaranteed to be secure or error-free as information could be 
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. The sender therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a 
result of e-mail transmission. If verification is required please 
request a hard-copy version.

Saint Mary's College, Shillong, Meghalaya, India-793003,
smcs.ac.in <http://smcs.ac.in>

___
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


--
Ronald Wimmer
Zachgasse 12/Haus 7
1220 Wien
Tel: +43 680 149 37 99
___
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:/

[Freeipa-users] Re: In FreeIPA AD trust environment add AD user to local group

2023-07-30 Thread Ronald Wimmer via FreeIPA-users

Have a look at 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WR7JQOMWCEXNABNSZGFF2FYN6ENEHEIB/#BBVO35ZP4YFI7C27NASZLYWRWDFY6DRH

Am 30. Juli 2023 11:17:37 MESZ schrieb Sameer Gurung via FreeIPA-users 
:
>I have integrated freeipa with AD via a two way trust. However I now have a
>problem
>
>How do I add my AD users logging in to linux clients to the local machines
>docker group so that they can run docker.
>Any help would be appreciated.
>Thanks everyone!
>
>Sameer K Gurung
>
>-- 
>This message contains confidential information and is intended only for the 
>individual named. If you are not the named addressee you should not 
>disseminate, distribute or copy this e-mail. Please notify the sender 
>immediately by e-mail if you have received this e-mail by mistake and 
>delete this e-mail from your system. E-mail transmission cannot be 
>guaranteed to be secure or error-free as information could be intercepted, 
>corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. 
>The sender therefore does not accept liability for any errors or omissions 
>in the contents of this message, which arise as a result of e-mail 
>transmission. If verification is required please request a hard-copy 
>version. Saint Mary's College, Shillong, Meghalaya, India-793003,
>smcs.ac.in 
___
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: sudo and hostnames

2023-06-29 Thread Ronald Wimmer via FreeIPA-users


On 29.06.23 09:52, Sam Morris via FreeIPA-users wrote:

On 29/06/2023 07:31, Ronald Wimmer via FreeIPA-users wrote:

Is a correct hostname (FQDN) required for sudo rules to work properly?

I do have a host where the hostname is set to its shortname. My user 
is allowed to perform sudo on this host (as it is a member of the 
admin group which is allowed to do everything on every host) but 
another user (who is not member of the admin group) cannot perform 
sudo on this particular host. (according to IPA this user should be 
able to use sudo)


My suspicion is that this might have to do with the hostname 
incorrectly set to its shortname and not to its FQDN.


See https://docs.pagure.org/sssd.sssd/users/sudo_troubleshooting.html 
for how to enable sudo and sssd-sudo logs - you should be able to see 
how sudo evaluates the rules recieved from the directory with the 
information from the logs.


In this particular case it does not help me as the IPA client is an AIX 
7.3 machine that does not have SSSD.


___
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: sudo and hostnames

2023-06-29 Thread Ronald Wimmer via FreeIPA-users


On 29.06.23 08:31, Ronald Wimmer via FreeIPA-users wrote:

Is a correct hostname (FQDN) required for sudo rules to work properly?

I do have a host where the hostname is set to its shortname. My user is 
allowed to perform sudo on this host (as it is a member of the admin 
group which is allowed to do everything on every host) but another user 
(who is not member of the admin group) cannot perform sudo on this 
particular host. (according to IPA this user should be able to use sudo)


My suspicion is that this might have to do with the hostname incorrectly 
set to its shortname and not to its FQDN.


In IPA's LDAP directory I can see cn and fqdn set to the server's FQDN 
but the serverHostName attribute is the server's shortname.

___
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] sudo and hostnames

2023-06-29 Thread Ronald Wimmer via FreeIPA-users


Is a correct hostname (FQDN) required for sudo rules to work properly?

I do have a host where the hostname is set to its shortname. My user is 
allowed to perform sudo on this host (as it is a member of the admin 
group which is allowed to do everything on every host) but another user 
(who is not member of the admin group) cannot perform sudo on this 
particular host. (according to IPA this user should be able to use sudo)


My suspicion is that this might have to do with the hostname incorrectly 
set to its shortname and not to its FQDN.


Is this plausible?

Cheers,
Ronald
___
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: Antivirus/malware scan

2023-06-26 Thread Ronald Wimmer via FreeIPA-users


On 26.06.23 16:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 26.06.23 09:32, Ronald Wimmer via FreeIPA-users wrote:

If a company policy forces you to install an antivirus/malware scan
tool on Linux servers which IPA directories should be excluded because
a severe performance impact would be very likely?

I would start with:
/var/lib/sss
/etc/dirsrv/slapd-LINUX-MYDOMAIN-AT

What else?


To be a little more precise I am talking about IPA servers themselves...


So you're trying to reduce/limit file I/O?

/etc/dirsrv doesn't contain much. The database is in
/var/lib/dirsrv/slapd-EXAMPLE-TEST/ and I think that's where you'd see
any performance hit reading and trying to do malware checks against huge
binary files.


Thanks for your input! Sorry. Of course I meant 
/var/lib/dirsrv/somedomain...


I'll let these two directories exclude by my colleagues.


___
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: AIX - IPA group membership

2023-06-26 Thread Ronald Wimmer via FreeIPA-users

On 23.06.23 11:34, Ronald Wimmer via FreeIPA-users wrote:

On 23.06.23 10:26, Ronald Wimmer via FreeIPA-users wrote:

On 21.06.23 17:29, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 16:08, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:57, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

I can and use IPA users on an AIX client. As well as groups. But
somehow
group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?

There isn't enough information. How is LDAP configured, what
search bases?

What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?

I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768
for example.

/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at

Which LDAP schema AIX configuration is expecting to use? RFC2307 or
RFC2307bis?

The primary LDAP tree in FreeIPA is using RFC2307bis (e.g.
member/memberof, not memberuid attributes).

I did not do the AIX client configuration by myself. I am just trying
to assist my AIX colleagues to find the problem...

What I saw were two map files in /etc/security/ldap named
2307user.map and 2307group.map. So I am suspecting that they are
trying to use RFC2307. In order to use that we would need to use a
different configuration? Is this where the compat tree comes into
place?

Correct. If your clients are using RFC2307, compat tree is what
could be

used to provide them the data in the format they expect. However, I'd
rather ask AIX admins to use RFC2307bis. For example,
https://www.ibm.com/support/pages/aix-how-configure-aix-ldap-or-krb5ldap-client

talks about other maps for AD (which is also using member/memberof,
not

memberuid).

Just to avoid any confusion. Is the link you provided an example for
2307bis configuration? I am asking because the term "2307bis" is not
mentioned at all in the article...

It isn't and the group configuration is rather subtle.

Near as I can tell you want to look for:

#users SEC_LIST memberUid m na yes
users SEC_LIST member m na yes

memberUid is RFC 2307 and member is RFC 2307bis.

I tried to configure an AIX client the bis way. Now the IPA group
shows its members. Perfect. However, the id command does not list the
IPA group. As a result, sudo commands do not work because these rights
were given to the IPA group.

I've added

groups SEC_LIST memberof s
na yes

to the 2307bisuser.map file because I thought that might fit. But
unfortunately it did not.

What might I be missing?

Forgot to mention that lsuser -R LDAP someuser also does not reveal the
IPA group.

Andrey Klyachkin from IBM answered my question on LinkedIn:
Ronald, did you check LDAP client mappings on AIX? By default if you
followed the article AIX will search for memberUid attribute in
cn=groups. It is RFC2307, not RFC2307bis. You can update
/etc/security/ldap/2307group.map (or create your own map) and define
member attribute instead of memberUid. After restart secldapclntd should
find the secondary groups.
Another possible confusion place - AIX expects usernames in member or
memberUid attribute. If your LDAP administrator wrote user's full CN in
the attribute instead of just username, AIX will not identify it as a
secondary group for the user. As far as I could test IPA doesn't allow
to write just usernames into the attribute and wants to have full CNs.
(https://www.linkedin.com/feed/update/urn:li:ugcPost:7059442334530207744?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7059442334530207744%2C7079018671796330496%29=urn%3Ali%3Acomment%3A%28ugcPost%3A7059442334530207744%2C7079041984954281984%29=urn%3Ali%3Afsd_comment%3A%287079018671796330496%2Curn%3Ali%3AugcPost%3A7059442334530207744%29=urn%3Ali%3Afsd_comment%3A%287079041984954281984%2Curn%3Ali%3AugcPost%3A7059442334530207744%29
)

Could this be the 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] Re: Antivirus/malware scan

2023-06-26 Thread Ronald Wimmer via FreeIPA-users


On 26.06.23 09:32, Ronald Wimmer via FreeIPA-users wrote:
If a company policy forces you to install an antivirus/malware scan tool 
on Linux servers which IPA directories should be excluded because a 
severe performance impact would be very likely?


I would start with:
/var/lib/sss
/etc/dirsrv/slapd-LINUX-MYDOMAIN-AT

What else?


To be a little more precise I am talking about IPA servers themselves...
___
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] Antivirus/malware scan

2023-06-26 Thread Ronald Wimmer via FreeIPA-users

If a company policy forces you to install an antivirus/malware scan tool 
on Linux servers which IPA directories should be excluded because a 
severe performance impact would be very likely?


I would start with:
/var/lib/sss
/etc/dirsrv/slapd-LINUX-MYDOMAIN-AT

What else?

Cheers,
Ronald
___
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: AIX - IPA group membership

2023-06-23 Thread Ronald Wimmer via FreeIPA-users


On 23.06.23 10:26, Ronald Wimmer via FreeIPA-users wrote:

On 21.06.23 17:29, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 16:08, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:57, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

I can and use IPA users on an AIX client. As well as groups. But
somehow
group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


There isn't enough information. How is LDAP configured, what
search bases?

What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?


I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768
for example.

/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at


Which LDAP schema AIX configuration is expecting to use? RFC2307 or
RFC2307bis?

The primary LDAP tree in FreeIPA is using RFC2307bis (e.g.
member/memberof, not memberuid attributes).


I did not do the AIX client configuration by myself. I am just trying
to assist my AIX colleagues to find the problem...

What I saw were two map files in /etc/security/ldap named
2307user.map and 2307group.map. So I am suspecting that they are
trying to use RFC2307. In order to use that we would need to use a
different configuration? Is this where the compat tree comes into 
place?


Correct. If your clients are using RFC2307, compat tree is what 
could be

used to provide them the data in the format they expect. However, I'd
rather ask AIX admins to use RFC2307bis. For example,
https://www.ibm.com/support/pages/aix-how-configure-aix-ldap-or-krb5ldap-client

talks about other maps for AD (which is also using member/memberof, not
memberuid).


Just to avoid any confusion. Is the link you provided an example for
2307bis configuration? I am asking because the term "2307bis" is not
mentioned at all in the article...


It isn't and the group configuration is rather subtle.

Near as I can tell you want to look for:

#users    SEC_LIST    memberUid    m    na    yes
users    SEC_LIST    member    m    na    yes

memberUid is RFC 2307 and member is RFC 2307bis.



I tried to configure an AIX client the bis way. Now the IPA group shows 
its members. Perfect. However, the id command does not list the IPA 
group. As a result, sudo commands do not work because these rights were 
given to the IPA group.


I've added

groups  SEC_LIST    memberof    s   na  yes

to the 2307bisuser.map file because I thought that might fit. But 
unfortunately it did not.


What might I be missing?


Forgot to mention that lsuser -R LDAP someuser also does not reveal the 
IPA group.

___
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: AIX - IPA group membership

2023-06-23 Thread Ronald Wimmer via FreeIPA-users


On 21.06.23 17:29, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 16:08, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:57, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

I can and use IPA users on an AIX client. As well as groups. But
somehow
group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


There isn't enough information. How is LDAP configured, what
search bases?

What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?


I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768
for example.

/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at


Which LDAP schema AIX configuration is expecting to use? RFC2307 or
RFC2307bis?

The primary LDAP tree in FreeIPA is using RFC2307bis (e.g.
member/memberof, not memberuid attributes).


I did not do the AIX client configuration by myself. I am just trying
to assist my AIX colleagues to find the problem...

What I saw were two map files in /etc/security/ldap named
2307user.map and 2307group.map. So I am suspecting that they are
trying to use RFC2307. In order to use that we would need to use a
different configuration? Is this where the compat tree comes into place?


Correct. If your clients are using RFC2307, compat tree is what could be
used to provide them the data in the format they expect. However, I'd
rather ask AIX admins to use RFC2307bis. For example,
https://www.ibm.com/support/pages/aix-how-configure-aix-ldap-or-krb5ldap-client

talks about other maps for AD (which is also using member/memberof, not
memberuid).


Just to avoid any confusion. Is the link you provided an example for
2307bis configuration? I am asking because the term "2307bis" is not
mentioned at all in the article...


It isn't and the group configuration is rather subtle.

Near as I can tell you want to look for:

#usersSEC_LISTmemberUidmnayes
usersSEC_LISTmembermnayes

memberUid is RFC 2307 and member is RFC 2307bis.



I tried to configure an AIX client the bis way. Now the IPA group shows 
its members. Perfect. However, the id command does not list the IPA 
group. As a result, sudo commands do not work because these rights were 
given to the IPA group.


I've added

groups  SEC_LISTmemberofs   na  yes

to the 2307bisuser.map file because I thought that might fit. But 
unfortunately it did not.


What might I be missing?


___
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: AIX - IPA group membership

2023-06-21 Thread Ronald Wimmer via FreeIPA-users


On 20.06.23 16:08, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:57, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:
I can and use IPA users on an AIX client. As well as groups. But 
somehow

group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


There isn't enough information. How is LDAP configured, what search 
bases?


What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?


I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768 for 
example.


/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at


Which LDAP schema AIX configuration is expecting to use? RFC2307 or
RFC2307bis?

The primary LDAP tree in FreeIPA is using RFC2307bis (e.g.
member/memberof, not memberuid attributes).


I did not do the AIX client configuration by myself. I am just trying 
to assist my AIX colleagues to find the problem...


What I saw were two map files in /etc/security/ldap named 2307user.map 
and 2307group.map. So I am suspecting that they are trying to use 
RFC2307. In order to use that we would need to use a different 
configuration? Is this where the compat tree comes into place?


Correct. If your clients are using RFC2307, compat tree is what could be
used to provide them the data in the format they expect. However, I'd
rather ask AIX admins to use RFC2307bis. For example,
https://www.ibm.com/support/pages/aix-how-configure-aix-ldap-or-krb5ldap-client
talks about other maps for AD (which is also using member/memberof, not
memberuid).


Just to avoid any confusion. Is the link you provided an example for 
2307bis configuration? I am asking because the term "2307bis" is not 
mentioned at all in the article...

___
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: AIX - IPA group membership

2023-06-20 Thread Ronald Wimmer via FreeIPA-users


On 20.06.23 16:08, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:57, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:
I can and use IPA users on an AIX client. As well as groups. But 
somehow

group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


There isn't enough information. How is LDAP configured, what search 
bases?


What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?


I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768 for 
example.


/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at


Which LDAP schema AIX configuration is expecting to use? RFC2307 or
RFC2307bis?

The primary LDAP tree in FreeIPA is using RFC2307bis (e.g.
member/memberof, not memberuid attributes).


I did not do the AIX client configuration by myself. I am just trying 
to assist my AIX colleagues to find the problem...


What I saw were two map files in /etc/security/ldap named 2307user.map 
and 2307group.map. So I am suspecting that they are trying to use 
RFC2307. In order to use that we would need to use a different 
configuration? Is this where the compat tree comes into place?


Correct. If your clients are using RFC2307, compat tree is what could be
used to provide them the data in the format they expect. However, I'd
rather ask AIX admins to use RFC2307bis. For example,
https://www.ibm.com/support/pages/aix-how-configure-aix-ldap-or-krb5ldap-client
talks about other maps for AD (which is also using member/memberof, not
memberuid).


Thanks for your input Alexander & Rob!

In my opinion RFC2307bis would also be the way to go. Thanks for the 
link. I'll have some time for that on Friday. I'll get back to this 
thread how it worked 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: AIX - IPA group membership

2023-06-20 Thread Ronald Wimmer via FreeIPA-users


On 20.06.23 15:57, Alexander Bokovoy wrote:

On Tue, 20 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:
I can and use IPA users on an AIX client. As well as groups. But 
somehow

group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


There isn't enough information. How is LDAP configured, what search 
bases?


What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?


I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768 for 
example.


/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at


Which LDAP schema AIX configuration is expecting to use? RFC2307 or
RFC2307bis?

The primary LDAP tree in FreeIPA is using RFC2307bis (e.g.
member/memberof, not memberuid attributes).


I did not do the AIX client configuration by myself. I am just trying to 
assist my AIX colleagues to find the problem...


What I saw were two map files in /etc/security/ldap named 2307user.map 
and 2307group.map. So I am suspecting that they are trying to use 
RFC2307. In order to use that we would need to use a different 
configuration? Is this where the compat tree comes into place?

___
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: AIX - IPA group membership

2023-06-20 Thread Ronald Wimmer via FreeIPA-users


On 20.06.23 15:51, Ronald Wimmer via FreeIPA-users wrote:

On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

I can and use IPA users on an AIX client. As well as groups. But somehow
group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


There isn't enough information. How is LDAP configured, what search 
bases?


What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?


I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768 for 
example.


/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at


I would expect the id command to list the IPA group and the lsgroup 
command do list the user's UID.


___
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: AIX - IPA group membership

2023-06-20 Thread Ronald Wimmer via FreeIPA-users


On 20.06.23 15:45, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

I can and use IPA users on an AIX client. As well as groups. But somehow
group membership does not seem to be configured correctly...

# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


There isn't enough information. How is LDAP configured, what search bases?

What is ipa-aix-g? What membership do you expect?

How does the group relate to the user you id'd?


I'll try to clarify.

ipa-aix-g is the IPA group containing several members as y179768 for 
example.


/etc/security/ldap/ldap.cfg:
userbasedn:cn=users,cn=accounts,dc=linux,dc=mydomain,dc=at
groupbasedn:cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at

___
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] AIX - IPA group membership

2023-06-20 Thread Ronald Wimmer via FreeIPA-users

I can and use IPA users on an AIX client. As well as groups. But somehow 
group membership does not seem to be configured correctly...


# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)

# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP

Anyone has a hint what could be misconfigured?


___
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 AIX - sudoers_base

2023-06-16 Thread Ronald Wimmer via FreeIPA-users


On 15.06.23 15:27, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 01.06.23 08:10, Ronald Wimmer via FreeIPA-users wrote:

On 31.05.23 20:18, Alexander Bokovoy wrote:

On Wed, 31 May 2023, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

We managed to integrate AIX IPA clients successfully some time ago.
sudo
was also working fine. A few weeks ago sudo stopped working.


It begs the question: what happened a few weeks ago? Did you upgrade
anything?


My AIX colleagues say no.



What version of IPA server?


What version of slapi-nis package?


Version  : 0.60.0
Release  : 1.module+el8.7.0+20837+581a7c1e


The /etc/ldap.conf on our AIX clients contains the following line:
sudoers_base cn=users,cn=compat,ou=sudoers,dc=linux,dc=mydomain,dc=at


I believe it should be ou=sudoers,dc=linux,dc=mydomain,dc=at


Why don't I see an ou=sudoers with an LDAP browser? Is there some kind
of magic going on I am not aware of?




If we try to look that up with an LDAP browser we do not even find
a OU
named "sudoers". Did the LDAP structure change in the recent past?
What
should the sudoers_base line contain?


Changes were made in slapi-nis which provides the compat tree but
like I
said, I don't know that cn=users,cn=compat,ou=sudoers would have ever
worked.


Indeed. That DN would have never matched anything.


I agree because that DN simply does not exist in the LDAP tree.



# grep -E 'dn: .*,cn=Schema Compatibility|schema-compat-container'
/etc/dirsrv/slapd-IPA-TEST/dse.ldif


Here is where confusion starts for me. What is that compat stuff?
Should I be able to see that in the LDAP tree with an LDAP browser or
is there a different mechanism in place? (I am only aware that one can
import and export ldif files...)


So... any hints here on how to proceed?


The compat trees are virtual and not advertised as backends which is why
LDAP browsers can't find them. Navigating directly to it should work, or
use ldapsearch.


Thank you! I could find it by navigating to it directly. Unfortunately, 
I do not see a "sudoers" entry in the compat tree. Where should it be 
located?





___
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 AIX - sudoers_base

2023-06-15 Thread Ronald Wimmer via FreeIPA-users


On 01.06.23 08:10, Ronald Wimmer via FreeIPA-users wrote:

On 31.05.23 20:18, Alexander Bokovoy wrote:

On Wed, 31 May 2023, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:
We managed to integrate AIX IPA clients successfully some time ago. 
sudo

was also working fine. A few weeks ago sudo stopped working.


It begs the question: what happened a few weeks ago? Did you upgrade
anything?


My AIX colleagues say no.



What version of IPA server?


What version of slapi-nis package?


Version  : 0.60.0
Release  : 1.module+el8.7.0+20837+581a7c1e


The /etc/ldap.conf on our AIX clients contains the following line:
sudoers_base cn=users,cn=compat,ou=sudoers,dc=linux,dc=mydomain,dc=at


I believe it should be ou=sudoers,dc=linux,dc=mydomain,dc=at


Why don't I see an ou=sudoers with an LDAP browser? Is there some kind 
of magic going on I am not aware of?





If we try to look that up with an LDAP browser we do not even find a OU
named "sudoers". Did the LDAP structure change in the recent past? What
should the sudoers_base line contain?


Changes were made in slapi-nis which provides the compat tree but like I
said, I don't know that cn=users,cn=compat,ou=sudoers would have ever
worked.


Indeed. That DN would have never matched anything.


I agree because that DN simply does not exist in the LDAP tree.



# grep -E 'dn: .*,cn=Schema Compatibility|schema-compat-container' 
/etc/dirsrv/slapd-IPA-TEST/dse.ldif


Here is where confusion starts for me. What is that compat stuff? Should 
I be able to see that in the LDAP tree with an LDAP browser or is there 
a different mechanism in place? (I am only aware that one can import and 
export ldif files...)


So... any hints here on how to proceed?


___
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: IPA fails to find certain AD groups

2023-06-12 Thread Ronald Wimmer via FreeIPA-users


On 08.06.23 07:52, Sumit Bose via FreeIPA-users wrote:

Am Wed, Jun 07, 2023 at 05:10:15PM +0200 schrieb Ronald Wimmer via 
FreeIPA-users:

On 07.06.23 17:07, Ronald Wimmer via FreeIPA-users wrote:

On 07.06.23 14:27, Ronald Wimmer via FreeIPA-users wrote:

When trying to add an AD group in an external group IPA fails to add
certain groups. Error: "trusted domain object not found"


What the AD objects that cannot be added have in common is that their
RID (last component of SID) is over 2.

Example group: 201455
Example user: 203766

So. I bet the ID ranges are set to small on the IPA side.

Is this plausible?


I's say yes...

   Range name: SOMEDOMAIN.MYDOMAIN.AT_id_range
   First Posix ID of the range: 107380
   Number of IDs in the range: 20
   First RID of the corresponding RID range: 0
   Domain SID of the trusted domain: 
   Range type: Active Directory domain range


Hi,

yes, the RIDs over 200k are most probably the reason the objects are not
seen. If you haven't started to change the idrange configuration I would
suggest to add a second idrange for this domain instead of changing just
the size of the range. The reason is the SSSD can add new idranges at
runtime but a change in an existing idrange requires a restart with
removing the cache. So just adding a new idrange will be less effort.


Thanks for the input. I added another id range for that particular 
domain and everything works perfectly fine now.


Cheers,
Ronald
___
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: IPA fails to find certain AD groups

2023-06-07 Thread Ronald Wimmer via FreeIPA-users


On 07.06.23 17:07, Ronald Wimmer via FreeIPA-users wrote:

On 07.06.23 14:27, Ronald Wimmer via FreeIPA-users wrote:
When trying to add an AD group in an external group IPA fails to add 
certain groups. Error: "trusted domain object not found"


What the AD objects that cannot be added have in common is that their 
RID (last component of SID) is over 2.


Example group: 201455
Example user: 203766

So. I bet the ID ranges are set to small on the IPA side.

Is this plausible?


I's say yes...

  Range name: SOMEDOMAIN.MYDOMAIN.AT_id_range
  First Posix ID of the range: 107380
  Number of IDs in the range: 20
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: 
  Range type: Active Directory domain range

___
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: IPA fails to find certain AD groups

2023-06-07 Thread Ronald Wimmer via FreeIPA-users


On 07.06.23 14:27, Ronald Wimmer via FreeIPA-users wrote:
When trying to add an AD group in an external group IPA fails to add 
certain groups. Error: "trusted domain object not found"


What the AD objects that cannot be added have in common is that their 
RID (last component of SID) is over 2.


Example group: 201455
Example user: 203766

So. I bet the ID ranges are set to small on the IPA side.

Is this plausible?

The remaining question is why a group that could already be added to IPA 
cannot be added anymore (RID 198387). The group is a domain local group. 
Maybe it could be added in the past due to a bug that is fixed now?


Cheers,
Ronald
___
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: Do keytabs expire?

2023-06-07 Thread Ronald Wimmer via FreeIPA-users


On 07.06.23 14:25, Simo Sorce via FreeIPA-users wrote:

On Wed, 2023-06-07 at 10:36 +0200, Ronald Wimmer via FreeIPA-users
wrote:

On 19.09.17 12:07, Alexander Bokovoy wrote:

On ti, 19 syys 2017, Ronald Wimmer wrote:

On 2017-09-19 11:53, Alexander Bokovoy wrote:

[...]
Please spend some time reading the documentation. It is vast and has a
lot of answers to questions people keep asking on these lists.


I've already spent some time reading the documentation. Since
"ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab
-r" would need:

ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com 
--hosts={node01.idm.example.com,node02.idm.example.com}

That's why I gave you these links as you have obviously didn't read
them.

Glad that it works now.


As we ran into this problem again it should be mentioned that restarting
gssproxy.service can be necessary.

In our case Apache was looking for a KVNO 1 whereas the actual file did
already have version number 4.



FWIW, gssapi should pick up new keys in keytabs without the need to
restart.


I had to fetch a new keytab for this particular host as the host was 
accidentally deleted in IPA. (would the old keytab file on the server 
still have worked after re-adding the host in IPA?)

___
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] IPA fails to find certain AD groups

2023-06-07 Thread Ronald Wimmer via FreeIPA-users

When trying to add an AD group in an external group IPA fails to add 
certain groups. Error: "trusted domain object not found"


These groups do definitely exist in AD. I checked every domain 
controller just to rule out an AD LDAP replication issue.


I tried to replace a domain local group with a global group in the exact 
same OU. (group name differs only in one single letter) Trying to add 
the new group in IPA fails. Trying to add the old one (that has 
previously worked in IPA) again does also fail.


VERSION: 4.9.11, API_VERSION: 2.251

I did some OS Updates recently containing:
0:idm-pki-acme-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.noarch
0:idm-pki-base-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.noarch
0:idm-pki-base-java-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.noarch
0:idm-pki-ca-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.noarch
0:idm-pki-kra-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.noarch
0:idm-pki-server-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.noarch
0:idm-pki-symkey-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.x86_64
0:idm-pki-tools-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.x86_64
0:ipa-client-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.x86_64
0:ipa-client-common-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.noarch
0:ipa-common-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.noarch
0:ipa-healthcheck-0.12-1.module+el8.8.0+21013+a1d8660b.noarch
0:ipa-healthcheck-core-0.12-1.module+el8.8.0+21013+a1d8660b.noarch
0:ipa-selinux-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.noarch
0:ipa-server-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.x86_64
0:ipa-server-common-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.noarch
0:ipa-server-trust-ad-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.x86_64

and

0:python3-idm-pki-10.14.3-1.0.1.module+el8.8.0+20999+6d4394a9.noarch
0:python3-ipaclient-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.noarch
0:python3-ipalib-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.noarch
0:python3-ipaserver-4.9.11-5.0.1.module+el8.8.0+21013+a1d8660b.noarch

(can provide full list if necessary)

Maybe I introduced some kind of bug when updating...

Cheers,
Ronald
___
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: Do keytabs expire?

2023-06-07 Thread Ronald Wimmer via FreeIPA-users


On 19.09.17 12:07, Alexander Bokovoy wrote:

On ti, 19 syys 2017, Ronald Wimmer wrote:

On 2017-09-19 11:53, Alexander Bokovoy wrote:

[...]
Please spend some time reading the documentation. It is vast and has a
lot of answers to questions people keep asking on these lists.


I've already spent some time reading the documentation. Since
"ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab
-r" would need:

ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com 
--hosts={node01.idm.example.com,node02.idm.example.com}

That's why I gave you these links as you have obviously didn't read
them.

Glad that it works now.


As we ran into this problem again it should be mentioned that restarting 
gssproxy.service can be necessary.


In our case Apache was looking for a KVNO 1 whereas the actual file did 
already have version number 4.


Cheers,
Ronald
___
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: AD user does not show up in IPA

2023-06-06 Thread Ronald Wimmer via FreeIPA-users


On 06.06.23 08:59, Alexander Bokovoy wrote:

On Tue, 06 Jun 2023, Ronald Wimmer via FreeIPA-users wrote:
We do have the problem that a user from an AD group does not show up 
in IPA whereas all other users of this particular group do. The AD 
group is used for PAM authorization in Apache.


The AD group is correctly mapped in IPA. However, the AD group is a 
domain local group. (shouldn't these groups not work at all in 
combination with IPA?)


They should not.

That's what I remembered. We will correct this as a first step. If the 
user still does not show up after that, I'll get back to this thread.



Cheers,
Ronald
___
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: AD user does not show up in IPA

2023-06-06 Thread Ronald Wimmer via FreeIPA-users


On 06.06.23 08:42, Ronald Wimmer via FreeIPA-users wrote:
We do have the problem that a user from an AD group does not show up 
in IPA whereas all other users of this particular group do. The AD 
group is used for PAM authorization in Apache.


The AD group is correctly mapped in IPA. However, the AD group is a 
domain local group. (shouldn't these groups not work at all in 
combination with IPA?)


The only thing we saw immediately in the log files was "user not known 
to the underlying PAM module". What else should we look for?
We will, of course, follow the SSSD troubleshooting steps 
(https://sssd.io/troubleshooting/basics.html ) but we did not have time 
to do so up to this moment.

___
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] AD user does not show up in IPA

2023-06-06 Thread Ronald Wimmer via FreeIPA-users

We do have the problem that a user from an AD group does not show up in 
IPA whereas all other users of this particular group do. The AD group is 
used for PAM authorization in Apache.


The AD group is correctly mapped in IPA. However, the AD group is a 
domain local group. (shouldn't these groups not work at all in 
combination with IPA?)


The only thing we saw immediately in the log files was "user not known 
to the underlying PAM module". What else should we look for?


Cheers,
Ronald
___
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 AIX - sudoers_base

2023-06-01 Thread Ronald Wimmer via FreeIPA-users


On 31.05.23 20:18, Alexander Bokovoy wrote:

On Wed, 31 May 2023, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

We managed to integrate AIX IPA clients successfully some time ago. sudo
was also working fine. A few weeks ago sudo stopped working.


It begs the question: what happened a few weeks ago? Did you upgrade
anything?


My AIX colleagues say no.



What version of IPA server?


What version of slapi-nis package?


Version  : 0.60.0
Release  : 1.module+el8.7.0+20837+581a7c1e


The /etc/ldap.conf on our AIX clients contains the following line:
sudoers_base cn=users,cn=compat,ou=sudoers,dc=linux,dc=mydomain,dc=at


I believe it should be ou=sudoers,dc=linux,dc=mydomain,dc=at


Why don't I see an ou=sudoers with an LDAP browser? Is there some kind 
of magic going on I am not aware of?





If we try to look that up with an LDAP browser we do not even find a OU
named "sudoers". Did the LDAP structure change in the recent past? What
should the sudoers_base line contain?


Changes were made in slapi-nis which provides the compat tree but like I
said, I don't know that cn=users,cn=compat,ou=sudoers would have ever
worked.


Indeed. That DN would have never matched anything.


I agree because that DN simply does not exist in the LDAP tree.



# grep -E 'dn: .*,cn=Schema Compatibility|schema-compat-container' 
/etc/dirsrv/slapd-IPA-TEST/dse.ldif


Here is where confusion starts for me. What is that compat stuff? Should 
I be able to see that in the LDAP tree with an LDAP browser or is there 
a different mechanism in place? (I am only aware that one can import and 
export ldif files...)


Cheers,
Ronald
___
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 and AIX - sudoers_base

2023-05-31 Thread Ronald Wimmer via FreeIPA-users

We managed to integrate AIX IPA clients successfully some time ago. sudo 
was also working fine. A few weeks ago sudo stopped working.


The /etc/ldap.conf on our AIX clients contains the following line:
sudoers_base cn=users,cn=compat,ou=sudoers,dc=linux,dc=mydomain,dc=at

If we try to look that up with an LDAP browser we do not even find a OU 
named "sudoers". Did the LDAP structure change in the recent past? What 
should the sudoers_base line contain?


Cheers,
Ronald
___
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: Disabled Domain fills IPA client sssd logs

2023-05-22 Thread Ronald Wimmer via FreeIPA-users


On 21.03.23 11:06, Ronald Wimmer via FreeIPA-users wrote:

On 17.02.23 09:51, Sumit Bose wrote:

Am Fri, Feb 17, 2023 at 08:51:03AM +0100 schrieb Ronald Wimmer:



On 16.02.23 12:18, Sumit Bose wrote:
Am Thu, Feb 16, 2023 at 12:14:02PM +0100 schrieb Ronald Wimmer via 
FreeIPA-users:
We do face the problem that we disabled a domain we do not need and 
that
this particular domain fills up sssd logs on the client side. 
Especially

sssd_nss.log. How could we possibly avoid this behavior?


Hi,

are you using the default debug level or did you set debug_level
explicitly in sssd.conf?

Can you give some examples of the debug message?



I raised the debug level. sssd_nss.log fills up with

(2023-02-17  8:44:52): [nss] [sss_dp_get_account_msg] (0x0400): Creating
request for [tk.MYDOMAIN.at][0x1][BE_REQ_USER][idnumber=1000:-]
(2023-02-17  8:44:52): [nss] [sbus_add_timeout] (0x2000): 0x5610c6661c90
(2023-02-17  8:44:52): [nss] [sss_dp_internal_get_send] (0x0400): 
Entering

request [0x5610c5282a80:1:1...@tk.mydomain.at]
(2023-02-17  8:44:52): [nss] [sbus_remove_timeout] (0x2000): 
0x5610c6661c90

(2023-02-17  8:44:52): [nss] [sbus_dispatch] (0x4000): dbus conn:
0x5610c6660820
(2023-02-17  8:44:52): [nss] [sbus_dispatch] (0x4000): Dispatching.
(2023-02-17  8:44:52): [nss] [sss_dp_get_reply] (0x0010): The Data 
Provider

returned an error [org.freedesktop.sssd.Error.DataProvider.Fatal]
(2023-02-17  8:44:52): [nss] [cache_req_common_dp_recv] (0x0040): CR 
#18:

Data Provider Error: 3, 5, Failed to get reply from Data Provider
(2023-02-17  8:44:52): [nss] [cache_req_common_dp_recv] (0x0400): CR 
#18:

Due to an error we will return cached data
(2023-02-17  8:44:52): [nss] [cache_req_search_cache] (0x0400): CR #18:
Looking up [UID:1...@tk.mydomain.at] in cache
(2023-02-17  8:44:52): [nss] [cache_req_search_cache] (0x0400): CR #18:
Object [UID:1...@tk.mydomain.at] was not found in cache
(2023-02-17  8:44:52): [nss] [cache_req_process_result] (0x0400): CR 
#18:

Finished: Not found
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
buero.MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
org.MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
tk.MYDOMAIN.at is Disabled
(2023-02-17  8:44:52): [nss] [nss_protocol_done] (0x4000): Sending 
reply:

not found
(2023-02-17  8:44:52): [nss] [sss_dp_req_destructor] (0x0400): Deleting
request: [0x5610c5282a80:1:1...@tk.mydomain.at]
(2023-02-17  8:44:52): [nss] [nss_getby_id] (0x0400): Input ID: 1000
(2023-02-17  8:44:52): [nss] [cache_req_set_plugin] (0x2000): CR #19:
Setting "User by ID" plugin
(2023-02-17  8:44:52): [nss] [cache_req_send] (0x0400): CR #19: New 
request

'User by ID'
(2023-02-17  8:44:52): [nss] [cache_req_select_domains] (0x0400): CR 
#19:

Performing a multi-domain search
(2023-02-17  8:44:52): [nss] [cache_req_search_domains] (0x0400): CR 
#19:

Search will check the cache and check the data provider
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [cache_req_validate_domain_type] (0x2000):
Request type POSIX-only for domain org.MYDOMAIN.at type POSIX is valid
(2023-02-17  8:44:52): [nss] [cache_req_set_domain] (0x0400): CR #19: 
Using

domain [org.MYDOMAIN.at]
(2023-02-17  8:44:52): [nss] [cache_req_search_send] (0x0400): CR #19:
Looking up UID:1...@org.mydomain.at
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19:
Checking negative cache for [UID:1...@org.mydomain.at]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/UID/org.MYDOMAIN.at/1000]
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19:
[UID:1...@org.mydomain.at] does not exist (negative cache)
(2023-02-17  8:44:52): [nss] [cache_req_validate_domain_type] (0x2000):
Request type POSIX-only for domain linux.MYDOMAIN.at type POSIX is valid
(2023-02-17  8:44:52): [nss] [cache_req_set_domain] (0x0400): CR #19: 
Using

domain [linux.MYDOMAIN.at]
(2023-02-17  8:44:52): [nss] [cache_req_search_send] (0x0400): CR #19:
Looking up UID:1...@linux.mydomain.at
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19:
Checking negative cache

[Freeipa-users] Re: IDView problem

2023-05-16 Thread Ronald Wimmer via FreeIPA-users


On 15.05.23 10:34, Florence Blanc-Renaud wrote:

Hi,

On Fri, May 12, 2023 at 5:47 PM Ronald Wimmer > wrote:


On 12.05.23 11:35, Florence Blanc-Renaud via FreeIPA-users wrote:
 > Hi,
 >
 > can you provide more details? Did you use the "Default Trust View"
 > idview or did you create another one? Which attributes did you
override
 > for your AD user?

Of course I can.  I should have provided more info in the first place...

I created an own ID view called "zsh" which overrides the login shell
for certain users on certain hosts (currently 2 hosts, one running
CentOS 7.9 and the other one running OL 9.1)


Are those hosts IPA servers or IPA clients? 


No. Both are IPA clients.


___
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: IDView problem

2023-05-12 Thread Ronald Wimmer via FreeIPA-users


On 12.05.23 11:35, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,

can you provide more details? Did you use the "Default Trust View" 
idview or did you create another one? Which attributes did you override 
for your AD user?


Of course I can.  I should have provided more info in the first place...

I created an own ID view called "zsh" which overrides the login shell 
for certain users on certain hosts (currently 2 hosts, one running 
CentOS 7.9 and the other one running OL 9.1)

___
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] IDView problem

2023-05-11 Thread Ronald Wimmer via FreeIPA-users

I tried to apply an ID-View to a single AD-User. The first thing I 
noticed that the short user name did not work anymore upon SSH login. I 
had to specifiy the user name with its FQDN.


The second problem I noticed is that under RHEL 9 that particular user 
somehow "lost" all its groups. The only group the id command revealed 
was the one with the user's UID. So group-based sudo permissions stopped 
working...


Cheers,
Ronald
___
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] Group permission problem

2023-04-19 Thread Ronald Wimmer via FreeIPA-users

I do have a file ztestfile created with user_a:somegroup with mode 660. 
If I open this particular file with user_b who belongs to the same group 
in vim I get "E212 - can't open file for writing".


user_a is an IPA user
user_b is an AD user
somegroup is an IPA posix group that hols an external (AD) group there 
user_b is a member of

Both users as well as the group are resolved properly.
We do have ignore_group_members set to true.

I tried echo "asdf" >> ztestfile. That surprisingly worked on an IPA 
client but did not on an IPA server.


What could be the problem here? Where would I see more?

Cheers,
Ronald
___
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: 2FA only for certain hosts/host groups

2023-03-30 Thread Ronald Wimmer via FreeIPA-users


On 29.03.23 23:06, Sam Morris via FreeIPA-users wrote:

On 29/03/2023 21:48, Ronald Wimmer via FreeIPA-users wrote:

On 29.03.23 22:30, Ronald Wimmer via FreeIPA-users wrote:
Is it possible to enforce the second factor for a user only when 
trying to login to specific hosts/host groups?


List here says yes... 
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/


I'm gonna give it a try.


Sorry. Clicked on send to early... As I understand the link above, it 
would just be a


ipa host-mod  --auth-ind=otp secure.linuxhost.at

instead of enabling the option for some user. Right?

(or ipa service-mod --auth-ind=otp http/secure.linuxhost.at for a 
certain service)


But when I set the auth indicator on a host it does not seem to work. 
What am I missing?


Get a new TGT without providing a second factor. Then request a service 
ticket for host/secure.linuxhost.at; the KDC should refuse to hand out a 
ticket since your TGT doesn't have the 'otp' authentication indicator.


https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html#kerberos-authentication-indicators

See also pam_sss_gss which can used to grant/deny authentication to a 
PAM service based on the authentication indicators present on the user's 
host/$HOSTNAME service ticket:


https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html#enforcing-authentication-indicators

Services that authenticate clients via Kerberos authentication are also 
able to find out which authentication indicators are present on a 
client's service ticket, but I think this is quite new functionality 
that isn't implemented outside of pam_sss_gss so far.


What does this mean for us trying to enable OTP as an additional factor 
on certain hosts? Would I have to configure SSH(d) in a different way?



___
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: 2FA only for certain hosts/host groups

2023-03-29 Thread Ronald Wimmer via FreeIPA-users


On 29.03.23 22:30, Ronald Wimmer via FreeIPA-users wrote:
Is it possible to enforce the second factor for a user only when trying 
to login to specific hosts/host groups?


List here says yes... 
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/


I'm gonna give it a try.


Sorry. Clicked on send to early... As I understand the link above, it 
would just be a


ipa host-mod  --auth-ind=otp secure.linuxhost.at

instead of enabling the option for some user. Right?

(or ipa service-mod --auth-ind=otp http/secure.linuxhost.at for a 
certain service)


But when I set the auth indicator on a host it does not seem to work. 
What am I missing?


Cheers,
Ronald
___
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] 2FA only for certain hosts/host groups

2023-03-29 Thread Ronald Wimmer via FreeIPA-users

Is it possible to enforce the second factor for a user only when trying 
to login to specific hosts/host groups?


List here says yes... 
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/ 



I'm gonna give it a try.

Cheers,
Ronald
___
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: Disabled Domain fills IPA client sssd logs

2023-03-21 Thread Ronald Wimmer via FreeIPA-users


On 17.02.23 09:51, Sumit Bose wrote:

Am Fri, Feb 17, 2023 at 08:51:03AM +0100 schrieb Ronald Wimmer:



On 16.02.23 12:18, Sumit Bose wrote:

Am Thu, Feb 16, 2023 at 12:14:02PM +0100 schrieb Ronald Wimmer via 
FreeIPA-users:

We do face the problem that we disabled a domain we do not need and that
this particular domain fills up sssd logs on the client side. Especially
sssd_nss.log. How could we possibly avoid this behavior?


Hi,

are you using the default debug level or did you set debug_level
explicitly in sssd.conf?

Can you give some examples of the debug message?



I raised the debug level. sssd_nss.log fills up with

(2023-02-17  8:44:52): [nss] [sss_dp_get_account_msg] (0x0400): Creating
request for [tk.MYDOMAIN.at][0x1][BE_REQ_USER][idnumber=1000:-]
(2023-02-17  8:44:52): [nss] [sbus_add_timeout] (0x2000): 0x5610c6661c90
(2023-02-17  8:44:52): [nss] [sss_dp_internal_get_send] (0x0400): Entering
request [0x5610c5282a80:1:1...@tk.mydomain.at]
(2023-02-17  8:44:52): [nss] [sbus_remove_timeout] (0x2000): 0x5610c6661c90
(2023-02-17  8:44:52): [nss] [sbus_dispatch] (0x4000): dbus conn:
0x5610c6660820
(2023-02-17  8:44:52): [nss] [sbus_dispatch] (0x4000): Dispatching.
(2023-02-17  8:44:52): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.sssd.Error.DataProvider.Fatal]
(2023-02-17  8:44:52): [nss] [cache_req_common_dp_recv] (0x0040): CR #18:
Data Provider Error: 3, 5, Failed to get reply from Data Provider
(2023-02-17  8:44:52): [nss] [cache_req_common_dp_recv] (0x0400): CR #18:
Due to an error we will return cached data
(2023-02-17  8:44:52): [nss] [cache_req_search_cache] (0x0400): CR #18:
Looking up [UID:1...@tk.mydomain.at] in cache
(2023-02-17  8:44:52): [nss] [cache_req_search_cache] (0x0400): CR #18:
Object [UID:1...@tk.mydomain.at] was not found in cache
(2023-02-17  8:44:52): [nss] [cache_req_process_result] (0x0400): CR #18:
Finished: Not found
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
buero.MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
org.MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain
tk.MYDOMAIN.at is Disabled
(2023-02-17  8:44:52): [nss] [nss_protocol_done] (0x4000): Sending reply:
not found
(2023-02-17  8:44:52): [nss] [sss_dp_req_destructor] (0x0400): Deleting
request: [0x5610c5282a80:1:1...@tk.mydomain.at]
(2023-02-17  8:44:52): [nss] [nss_getby_id] (0x0400): Input ID: 1000
(2023-02-17  8:44:52): [nss] [cache_req_set_plugin] (0x2000): CR #19:
Setting "User by ID" plugin
(2023-02-17  8:44:52): [nss] [cache_req_send] (0x0400): CR #19: New request
'User by ID'
(2023-02-17  8:44:52): [nss] [cache_req_select_domains] (0x0400): CR #19:
Performing a multi-domain search
(2023-02-17  8:44:52): [nss] [cache_req_search_domains] (0x0400): CR #19:
Search will check the cache and check the data provider
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [cache_req_validate_domain_type] (0x2000):
Request type POSIX-only for domain org.MYDOMAIN.at type POSIX is valid
(2023-02-17  8:44:52): [nss] [cache_req_set_domain] (0x0400): CR #19: Using
domain [org.MYDOMAIN.at]
(2023-02-17  8:44:52): [nss] [cache_req_search_send] (0x0400): CR #19:
Looking up UID:1...@org.mydomain.at
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19:
Checking negative cache for [UID:1...@org.mydomain.at]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking
negative cache for [NCE/UID/org.MYDOMAIN.at/1000]
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19:
[UID:1...@org.mydomain.at] does not exist (negative cache)
(2023-02-17  8:44:52): [nss] [cache_req_validate_domain_type] (0x2000):
Request type POSIX-only for domain linux.MYDOMAIN.at type POSIX is valid
(2023-02-17  8:44:52): [nss] [cache_req_set_domain] (0x0400): CR #19: Using
domain [linux.MYDOMAIN.at]
(2023-02-17  8:44:52): [nss] [cache_req_search_send] (0x0400): CR #19:
Looking up UID:1...@linux.mydomain.at
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19:
Checking negative cache for [UID:1...@linux.mydomain.at]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_st

[Freeipa-users] Creating and modifying users from an external system

2023-03-18 Thread Ronald Wimmer via FreeIPA-users

We have several scenarios where we cannot establish an AD Trust. In 
these cases we are forced to create/modify/delete IPA users triggered 
from an IAM system. Is the IPA API the one and only way to go or would 
it also work if we used IPA's LDAP directly?


Cheers,
Ronald
___
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-Kubernetes Setup

2023-03-18 Thread Ronald Wimmer via FreeIPA-users


On 17.03.23 15:32, Alexander Bokovoy wrote:

On pe, 17 maalis 2023, Rob Crittenden via FreeIPA-users wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 14.05.21 11:26, Ronald Wimmer via FreeIPA-users wrote:

Hi,

are there any plans (or maybe ongoing work already) to let FreeIPA run
in a K8s environment?


What about tearing all the tightly coupled parts (389DS, DNS, PKI,
HTTPD, KDC, Samba, ...) apart, let them run in K8s and do the coupling
there?

Could that work if somebody took the effort (with support from the IPA
devs I would be willing to) or are there real showstoppers preventing
such an adventure?


It could require a re-architecture of IPA. Some services rely on ldapi
bind to connect to 389. You'd need to switch from that socket to a TCP
socket and pass the requisite bind credentials (DM). Services rely on
files in various places which if done systematically might not be too
bad, but might require creative bind mounting and/or duplicating files.
Installing it might require a pretty massive rewrite as it assumes a
monolith. Upgrades would be another challenge.

I don't know enough about K8S to know how naming would work to tie a
bunch of different nodes into a single "service" with a common name.

I don't know how well scaling would work either, if that's a goal.


It will not work well.

Performance differences between TCP/IP and UNIX domain sockets are huge.

There is roughly 60% of latency difference. There is 9x throughput
difference on a bare metal system. See 
https://github.com/rigtorp/ipc-bench for

the test code.

On virtual machines in a datacenter using KVM I am reliably getting
roughly 2x slowdown in both throughput and latency.

That is a starting point. I would not even go into technical details
requiring a tight collaboration between multiple DC components we have
right now.

Ok. I got it. So maybe deploying several containerized 
FreeIPA-Server-Instances would work. I'll give that a try.


As always, thanks a lot for your input!

Cheers,
Ronald
___
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-Kubernetes Setup

2023-03-17 Thread Ronald Wimmer via FreeIPA-users


On 14.05.21 11:26, Ronald Wimmer via FreeIPA-users wrote:

Hi,

are there any plans (or maybe ongoing work already) to let FreeIPA run 
in a K8s environment?


What about tearing all the tightly coupled parts (389DS, DNS, PKI, 
HTTPD, KDC, Samba, ...) apart, let them run in K8s and do the coupling 
there?


Could that work if somebody took the effort (with support from the IPA 
devs I would be willing to) or are there real showstoppers preventing 
such an adventure?


Cheers,
Ronald
___
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: Kerberized NFS and IPA

2023-03-16 Thread Ronald Wimmer via FreeIPA-users


On 16.03.23 09:50, Alexander Bokovoy wrote:

On to, 16 maalis 2023, Ronald Wimmer wrote:

On 16.03.23 09:09, Alexander Bokovoy via FreeIPA-users wrote:

On to, 16 maalis 2023, Ronald Wimmer wrote:

On 15.03.23 11:45, Alexander Bokovoy wrote:

On ke, 15 maalis 2023, Ronald Wimmer wrote:

On 15.03.23 10:12, Alexander Bokovoy via FreeIPA-users wrote:

On ti, 14 maalis 2023, Ronald Wimmer via FreeIPA-users wrote:
We enrolled a RHEL9 server (ipa client) in order to replace an 
old one (Centos 7.9). Unfortunately, windows users could not 
access their kerberized NFS home share.


Today I rechecked the server and saw that the "trusted for 
delegation" flag was not set. (it was set on the old Centos 
server) I enabled it and now it seems to work.


Was this probably just a coincidence or can it be explained 
somehow?


If you enrolled a new server, it does not have 'trusted for 
delegation'
by default. If it is the same hostname, during enrollment the 
object in

LDAP is removed, so all the flags on it are removed as well. For all
purposes, this is a new object, nothing from old state is preserved.



The documentation says:

OK_AS_DELEGATE
Use this flag to specify Kerberos tickets trusted for delegation.
Active directory (AD) clients check the OK_AS_DELEGATE flag on 
the Kerberos ticket to
determine whether the user credentials can be forwarded or 
delegated to the specific server. AD
forwards the ticket-granting ticket (TGT) only to services or 
hosts with OK_AS_DELEGATE set.
With this flag, system security services daemon (SSSD) can add 
the AD user TGT to the default

Kerberos credentials cache on the IdM client machine.


Is it needed that the TGT ticket can be forwarded to the server 
in order to let the server fetch the NFS-Ticket needed?


Yes, in the current implementation. We are working on supporting
resource-based constrained delegation (RBCD) which is required by
Microsoft to allow delegation of user credentials without TGT.


Why do I only see the TGT and no NFS ticket on the target server?


Depends on how you have it set up. When using GSSProxy for NFS, it 
would

be encrypted and not visible by the klist.


What I do not fully understand is the fact that I could login to 
that particular machine using my Kerberos credentials but NFS did 
not work. Why does a kerberized user login work without having 
"trusted for delegation" set on that particular target host?


Kerberos based login (I assume to SSH server) will authenticate against
SSH daemon. That's all it needs to do, no TGT delegation is needed for
that.

NFS client needs to authenticate to NFS server and if it uses GSSAPI, it
needs a valid service ticket to nfs/... service. If that ticket does not
exist in the credentials cache associated with the user under which a
process trying to access an NFS mount runs, then NFS client would try to
obtain the service ticket. To do that, it needs a TGT.

When you logged in via SSH protocol, if you have authenticated with
Kerberos, your TGT is not delegated by default, hence your credential
cache after login will not have a TGT and NFS client could not obtain a
service ticket to nfs/... service.


Thanks for clarifying this. Up to now I thought that "trusted for 
delegation" stands for all Kerberos credentials whereas it actually 
refers to the TGT only, right?




That's only what matters for unconstrained delegation (OK_AS_DELEGATE).

For constrained delegation there is a special process through which a
server in the middle would request a service ticket from a KDC on behalf
of the user. This process assumes several things:

  - KDC is configured to allow the issuance
  - an application that requests a ticket follows a special process
  - an application has a service ticket presented to it by the user

The process is described in the Microsoft's MS-SFU (Services for User)
Kerberos extensions and is fairly complex in itself.

When you login to SSH server, the SSH daemon will validate a service
ticket presented to it by the SSH client and will throw it away because
it is not needed anymore. You would have no Kebreros ticket in the
credential cache of your logged-in session on this machine. This means
the next application (NFS client) cannot perform its request to KDC to
ask for a ticket to NFS server on behalf of the user because:

  - it does not have a user's service ticket to itself (host/.. service
    that both NFS client and SSH server can share),

  - this ticket, even if it was present there, is not forwardable

  - NFS client also generally does not understand the special process
    that KDC requires Kerberos clients to use to request constrained
    delegation tickets.

GSSProxy knowns this process and if NFS client is configured to use
GSSProxy, it could also be configured to use constrained delegation as
well. However, this needs additional setup by administrators because:

  - GSSProxy still has no user's service ticket to host/.. service, so it
    has to use

[Freeipa-users] Re: Kerberized NFS and IPA

2023-03-16 Thread Ronald Wimmer via FreeIPA-users


On 16.03.23 09:09, Alexander Bokovoy via FreeIPA-users wrote:

On to, 16 maalis 2023, Ronald Wimmer wrote:

On 15.03.23 11:45, Alexander Bokovoy wrote:

On ke, 15 maalis 2023, Ronald Wimmer wrote:

On 15.03.23 10:12, Alexander Bokovoy via FreeIPA-users wrote:

On ti, 14 maalis 2023, Ronald Wimmer via FreeIPA-users wrote:
We enrolled a RHEL9 server (ipa client) in order to replace an old 
one (Centos 7.9). Unfortunately, windows users could not access 
their kerberized NFS home share.


Today I rechecked the server and saw that the "trusted for 
delegation" flag was not set. (it was set on the old Centos 
server) I enabled it and now it seems to work.


Was this probably just a coincidence or can it be explained somehow?


If you enrolled a new server, it does not have 'trusted for 
delegation'
by default. If it is the same hostname, during enrollment the 
object in

LDAP is removed, so all the flags on it are removed as well. For all
purposes, this is a new object, nothing from old state is preserved.



The documentation says:

OK_AS_DELEGATE
Use this flag to specify Kerberos tickets trusted for delegation.
Active directory (AD) clients check the OK_AS_DELEGATE flag on 
the Kerberos ticket to
determine whether the user credentials can be forwarded or 
delegated to the specific server. AD
forwards the ticket-granting ticket (TGT) only to services or 
hosts with OK_AS_DELEGATE set.
With this flag, system security services daemon (SSSD) can add 
the AD user TGT to the default

Kerberos credentials cache on the IdM client machine.


Is it needed that the TGT ticket can be forwarded to the server in 
order to let the server fetch the NFS-Ticket needed?


Yes, in the current implementation. We are working on supporting
resource-based constrained delegation (RBCD) which is required by
Microsoft to allow delegation of user credentials without TGT.


Why do I only see the TGT and no NFS ticket on the target server?


Depends on how you have it set up. When using GSSProxy for NFS, it would
be encrypted and not visible by the klist.


What I do not fully understand is the fact that I could login to that 
particular machine using my Kerberos credentials but NFS did not work. 
Why does a kerberized user login work without having "trusted for 
delegation" set on that particular target host?


Kerberos based login (I assume to SSH server) will authenticate against
SSH daemon. That's all it needs to do, no TGT delegation is needed for
that.

NFS client needs to authenticate to NFS server and if it uses GSSAPI, it
needs a valid service ticket to nfs/... service. If that ticket does not
exist in the credentials cache associated with the user under which a
process trying to access an NFS mount runs, then NFS client would try to
obtain the service ticket. To do that, it needs a TGT.

When you logged in via SSH protocol, if you have authenticated with
Kerberos, your TGT is not delegated by default, hence your credential
cache after login will not have a TGT and NFS client could not obtain a
service ticket to nfs/... service.


Thanks for clarifying this. Up to now I thought that "trusted for 
delegation" stands for all Kerberos credentials whereas it actually 
refers to the TGT only, right?

___
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: Kerberized NFS and IPA

2023-03-16 Thread Ronald Wimmer via FreeIPA-users


On 16.03.23 09:09, Alexander Bokovoy wrote:

On to, 16 maalis 2023, Ronald Wimmer wrote:

On 15.03.23 11:45, Alexander Bokovoy wrote:

On ke, 15 maalis 2023, Ronald Wimmer wrote:

On 15.03.23 10:12, Alexander Bokovoy via FreeIPA-users wrote:

On ti, 14 maalis 2023, Ronald Wimmer via FreeIPA-users wrote:
We enrolled a RHEL9 server (ipa client) in order to replace an old 
one (Centos 7.9). Unfortunately, windows users could not access 
their kerberized NFS home share.


Today I rechecked the server and saw that the "trusted for 
delegation" flag was not set. (it was set on the old Centos 
server) I enabled it and now it seems to work.


Was this probably just a coincidence or can it be explained somehow?


If you enrolled a new server, it does not have 'trusted for 
delegation'
by default. If it is the same hostname, during enrollment the 
object in

LDAP is removed, so all the flags on it are removed as well. For all
purposes, this is a new object, nothing from old state is preserved.



The documentation says:

OK_AS_DELEGATE
Use this flag to specify Kerberos tickets trusted for delegation.
Active directory (AD) clients check the OK_AS_DELEGATE flag on 
the Kerberos ticket to
determine whether the user credentials can be forwarded or 
delegated to the specific server. AD
forwards the ticket-granting ticket (TGT) only to services or 
hosts with OK_AS_DELEGATE set.
With this flag, system security services daemon (SSSD) can add 
the AD user TGT to the default

Kerberos credentials cache on the IdM client machine.


Is it needed that the TGT ticket can be forwarded to the server in 
order to let the server fetch the NFS-Ticket needed?


Yes, in the current implementation. We are working on supporting
resource-based constrained delegation (RBCD) which is required by
Microsoft to allow delegation of user credentials without TGT.


Why do I only see the TGT and no NFS ticket on the target server?


Depends on how you have it set up. When using GSSProxy for NFS, it would
be encrypted and not visible by the klist.


What I do not fully understand is the fact that I could login to that 
particular machine using my Kerberos credentials but NFS did not work. 
Why does a kerberized user login work without having "trusted for 
delegation" set on that particular target host?


Kerberos based login (I assume to SSH server) will authenticate against
SSH daemon. That's all it needs to do, no TGT delegation is needed for
that.

NFS client needs to authenticate to NFS server and if it uses GSSAPI, it
needs a valid service ticket to nfs/... service. If that ticket does not
exist in the credentials cache associated with the user under which a
process trying to access an NFS mount runs, then NFS client would try to
obtain the service ticket. To do that, it needs a TGT.

When you logged in via SSH protocol, if you have authenticated with
Kerberos, your TGT is not delegated by default, hence your credential
cache after login will not have a TGT and NFS client could not obtain a
service ticket to nfs/... service.


So "trusted for delegation" only refers to the TGT delegation, right?

___
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: Kerberized NFS and IPA

2023-03-16 Thread Ronald Wimmer via FreeIPA-users


On 15.03.23 11:45, Alexander Bokovoy wrote:

On ke, 15 maalis 2023, Ronald Wimmer wrote:

On 15.03.23 10:12, Alexander Bokovoy via FreeIPA-users wrote:

On ti, 14 maalis 2023, Ronald Wimmer via FreeIPA-users wrote:
We enrolled a RHEL9 server (ipa client) in order to replace an old 
one (Centos 7.9). Unfortunately, windows users could not access 
their kerberized NFS home share.


Today I rechecked the server and saw that the "trusted for 
delegation" flag was not set. (it was set on the old Centos server) 
I enabled it and now it seems to work.


Was this probably just a coincidence or can it be explained somehow?


If you enrolled a new server, it does not have 'trusted for delegation'
by default. If it is the same hostname, during enrollment the object in
LDAP is removed, so all the flags on it are removed as well. For all
purposes, this is a new object, nothing from old state is preserved.



The documentation says:

OK_AS_DELEGATE
Use this flag to specify Kerberos tickets trusted for delegation.
Active directory (AD) clients check the OK_AS_DELEGATE flag on the 
Kerberos ticket to
determine whether the user credentials can be forwarded or 
delegated to the specific server. AD
forwards the ticket-granting ticket (TGT) only to services or hosts 
with OK_AS_DELEGATE set.
With this flag, system security services daemon (SSSD) can add the 
AD user TGT to the default

Kerberos credentials cache on the IdM client machine.


Is it needed that the TGT ticket can be forwarded to the server in 
order to let the server fetch the NFS-Ticket needed?


Yes, in the current implementation. We are working on supporting
resource-based constrained delegation (RBCD) which is required by
Microsoft to allow delegation of user credentials without TGT.


Why do I only see the TGT and no NFS ticket on the target server?


Depends on how you have it set up. When using GSSProxy for NFS, it would
be encrypted and not visible by the klist.


What I do not fully understand is the fact that I could login to that 
particular machine using my Kerberos credentials but NFS did not work. 
Why does a kerberized user login work without having "trusted for 
delegation" set on that particular target host?


Cheers,
Ronald
___
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: Kerberized NFS and IPA

2023-03-15 Thread Ronald Wimmer via FreeIPA-users


On 15.03.23 10:12, Alexander Bokovoy via FreeIPA-users wrote:

On ti, 14 maalis 2023, Ronald Wimmer via FreeIPA-users wrote:
We enrolled a RHEL9 server (ipa client) in order to replace an old one 
(Centos 7.9). Unfortunately, windows users could not access their 
kerberized NFS home share.


Today I rechecked the server and saw that the "trusted for delegation" 
flag was not set. (it was set on the old Centos server) I enabled it 
and now it seems to work.


Was this probably just a coincidence or can it be explained somehow?


If you enrolled a new server, it does not have 'trusted for delegation'
by default. If it is the same hostname, during enrollment the object in
LDAP is removed, so all the flags on it are removed as well. For all
purposes, this is a new object, nothing from old state is preserved.



The documentation says:

OK_AS_DELEGATE
Use this flag to specify Kerberos tickets trusted for delegation.
Active directory (AD) clients check the OK_AS_DELEGATE flag on the 
Kerberos ticket to
determine whether the user credentials can be forwarded or delegated 
to the specific server. AD
forwards the ticket-granting ticket (TGT) only to services or hosts 
with OK_AS_DELEGATE set.
With this flag, system security services daemon (SSSD) can add the AD 
user TGT to the default

Kerberos credentials cache on the IdM client machine.


Is it needed that the TGT ticket can be forwarded to the server in 
order to let the server fetch the NFS-Ticket needed?


Yes, in the current implementation. We are working on supporting
resource-based constrained delegation (RBCD) which is required by
Microsoft to allow delegation of user credentials without TGT.


Why do I only see the TGT and no NFS ticket on the target server?

Cheers,
Ronald
___
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] Kerberized NFS and IPA

2023-03-14 Thread Ronald Wimmer via FreeIPA-users

We enrolled a RHEL9 server (ipa client) in order to replace an old one 
(Centos 7.9). Unfortunately, windows users could not access their 
kerberized NFS home share.


Today I rechecked the server and saw that the "trusted for delegation" 
flag was not set. (it was set on the old Centos server) I enabled it and 
now it seems to work.


Was this probably just a coincidence or can it be explained somehow?

The documentation says:

OK_AS_DELEGATE
Use this flag to specify Kerberos tickets trusted for delegation.
Active directory (AD) clients check the OK_AS_DELEGATE flag on the Kerberos 
ticket to
determine whether the user credentials can be forwarded or delegated to the 
specific server. AD
forwards the ticket-granting ticket (TGT) only to services or hosts with 
OK_AS_DELEGATE set.
With this flag, system security services daemon (SSSD) can add the AD user TGT 
to the default
Kerberos credentials cache on the IdM client machine.


Is it needed that the TGT ticket can be forwarded to the server in order 
to let the server fetch the NFS-Ticket needed?


Cheers,
Ronald

___
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: Ensure that IPA user can be resolved upon SystemD-Unit start

2023-02-17 Thread Ronald Wimmer via FreeIPA-users

On 12.01.23 17:19, Ronald Wimmer via FreeIPA-users wrote:

On 12.01.23 16:28, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

I do have a sytemd service unit that uses an IPA used. However, upon
reboot it seems that that particular IPA user is not available upon
start of that particular systemd service.

Using "After=sssd.service" is not sufficient.

What would you recommend in this case?
(I am looking for a reliable systemd solution and do not want to rely on
a script checking for a particular user with getent for example)

You may want to cross-post to the sssd-users list.

I'd try nss-user-lookup.target instead. According to systemd.special(7):

nss-user-lookup.target

A target that should be used as synchronization point for all regular
UNIX user/group name service lookups. Note that this is independent of
host/network name lookups for which nss-lookup.target should be used.
All services for which the availability of the full user/group database
is essential should be ordered after this target, but not pull it in.
All services which provide parts of the user/group database should be
ordered before this target, and pull it in. Note that this unit is only
relevant for regular users and groups — system users and groups are
required to be resolvable during earliest boot already, and hence do not
need any special ordering against this target.

Thanks for your input Rob! Unfortunately, nss-lookup.target also seems
not to be sufficient. I've asked in the SSSD mailing list:
https://lists.fedorahosted.org/archives/list/sssd-us...@lists.fedorahosted.org/thread/5E2RCVT36NBIRFUKW4ZKMMIDM6UJOR52/

This is another topic I need to bump as there was no response in the
SSSD users mailing list. Maybe Pavel can give some input here?

Cheers,
Ron
___
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: Disabled Domain fills IPA client sssd logs

2023-02-16 Thread Ronald Wimmer via FreeIPA-users




On 16.02.23 12:18, Sumit Bose wrote:

Am Thu, Feb 16, 2023 at 12:14:02PM +0100 schrieb Ronald Wimmer via 
FreeIPA-users:

We do face the problem that we disabled a domain we do not need and that
this particular domain fills up sssd logs on the client side. Especially
sssd_nss.log. How could we possibly avoid this behavior?


Hi,

are you using the default debug level or did you set debug_level
explicitly in sssd.conf?

Can you give some examples of the debug message?



I raised the debug level. sssd_nss.log fills up with

(2023-02-17  8:44:52): [nss] [sss_dp_get_account_msg] (0x0400): Creating 
request for [tk.MYDOMAIN.at][0x1][BE_REQ_USER][idnumber=1000:-]

(2023-02-17  8:44:52): [nss] [sbus_add_timeout] (0x2000): 0x5610c6661c90
(2023-02-17  8:44:52): [nss] [sss_dp_internal_get_send] (0x0400): 
Entering request [0x5610c5282a80:1:1...@tk.mydomain.at]

(2023-02-17  8:44:52): [nss] [sbus_remove_timeout] (0x2000): 0x5610c6661c90
(2023-02-17  8:44:52): [nss] [sbus_dispatch] (0x4000): dbus conn: 
0x5610c6660820

(2023-02-17  8:44:52): [nss] [sbus_dispatch] (0x4000): Dispatching.
(2023-02-17  8:44:52): [nss] [sss_dp_get_reply] (0x0010): The Data 
Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Fatal]
(2023-02-17  8:44:52): [nss] [cache_req_common_dp_recv] (0x0040): CR 
#18: Data Provider Error: 3, 5, Failed to get reply from Data Provider
(2023-02-17  8:44:52): [nss] [cache_req_common_dp_recv] (0x0400): CR 
#18: Due to an error we will return cached data
(2023-02-17  8:44:52): [nss] [cache_req_search_cache] (0x0400): CR #18: 
Looking up [UID:1...@tk.mydomain.at] in cache
(2023-02-17  8:44:52): [nss] [cache_req_search_cache] (0x0400): CR #18: 
Object [UID:1...@tk.mydomain.at] was not found in cache
(2023-02-17  8:44:52): [nss] [cache_req_process_result] (0x0400): CR 
#18: Finished: Not found
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain 
buero.MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain 
MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain 
org.MYDOMAIN.at is Active
(2023-02-17  8:44:52): [nss] [sss_domain_get_state] (0x1000): Domain 
tk.MYDOMAIN.at is Disabled
(2023-02-17  8:44:52): [nss] [nss_protocol_done] (0x4000): Sending 
reply: not found
(2023-02-17  8:44:52): [nss] [sss_dp_req_destructor] (0x0400): Deleting 
request: [0x5610c5282a80:1:1...@tk.mydomain.at]

(2023-02-17  8:44:52): [nss] [nss_getby_id] (0x0400): Input ID: 1000
(2023-02-17  8:44:52): [nss] [cache_req_set_plugin] (0x2000): CR #19: 
Setting "User by ID" plugin
(2023-02-17  8:44:52): [nss] [cache_req_send] (0x0400): CR #19: New 
request 'User by ID'
(2023-02-17  8:44:52): [nss] [cache_req_select_domains] (0x0400): CR 
#19: Performing a multi-domain search
(2023-02-17  8:44:52): [nss] [cache_req_search_domains] (0x0400): CR 
#19: Search will check the cache and check the data provider
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking 
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking 
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking 
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking 
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking 
negative cache for [NCE/DOM_LOCATE_TYPE/linux.MYDOMAIN.at/User by ID]
(2023-02-17  8:44:52): [nss] [cache_req_validate_domain_type] (0x2000): 
Request type POSIX-only for domain org.MYDOMAIN.at type POSIX is valid
(2023-02-17  8:44:52): [nss] [cache_req_set_domain] (0x0400): CR #19: 
Using domain [org.MYDOMAIN.at]
(2023-02-17  8:44:52): [nss] [cache_req_search_send] (0x0400): CR #19: 
Looking up UID:1...@org.mydomain.at
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19: 
Checking negative cache for [UID:1...@org.mydomain.at]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking 
negative cache for [NCE/UID/org.MYDOMAIN.at/1000]
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19: 
[UID:1...@org.mydomain.at] does not exist (negative cache)
(2023-02-17  8:44:52): [nss] [cache_req_validate_domain_type] (0x2000): 
Request type POSIX-only for domain linux.MYDOMAIN.at type POSIX is valid
(2023-02-17  8:44:52): [nss] [cache_req_set_domain] (0x0400): CR #19: 
Using domain [linux.MYDOMAIN.at]
(2023-02-17  8:44:52): [nss] [cache_req_search_send] (0x0400): CR #19: 
Looking up UID:1...@linux.mydomain.at
(2023-02-17  8:44:52): [nss] [cache_req_search_ncache] (0x0400): CR #19: 
Checking negative cache for [UID:1...@linux.mydomain.at]
(2023-02-17  8:44:52): [nss] [sss_ncache_check_str] (0x2000): Checking 
negative cache for [NCE/UID/linux.MYDOMAIN.at/1000

[Freeipa-users] Disabled Domain fills IPA client sssd logs

2023-02-16 Thread Ronald Wimmer via FreeIPA-users

We do face the problem that we disabled a domain we do not need and that 
this particular domain fills up sssd logs on the client side. Especially 
sssd_nss.log. How could we possibly avoid this behavior?


Cheers,
Ronald
___
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: Trust-Agents

2023-01-17 Thread Ronald Wimmer via FreeIPA-users

On 17.01.23 10:07, Alexander Bokovoy wrote:

On ti, 17 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:

On 16.01.23 21:46, Alexander Bokovoy wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:

On 16.01.23 20:16, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:

On 16.01.23 15:48, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:
I have a setup where we have four IPA servers. Two of them are
able to talk to the AD Domain Controllers directly. I set them
up as AD Trust controllers.

The other two IPA servers can only talk to these IPA servers
and not to the AD DCs directly. Thats why I wanted them to have
the Trust Agent Role only.

Trust Agent also should be able to talk to AD DCs. If those servers
cannot talk to AD DCs, they cannot be trust agents.

So it seems that I have misunderstood how trust agents can be
used. I thought AD communication is only done on trust
controllers whereas trust agents are some kind of proxies.

They aren't proxies but since they don't run DC services expected by
Active Directory domain controllers, they cannot be contacted by
AD DCs
to perform normal LSA RPC calls. So they are agents in this sense:
they
cannot participate in DC to DC communication with Active Directory
DCs.
Identity resolution on agents is performed by SSSD which talks to
LDAP

services of AD DCs, not the other direction.

Thanks for clarifying that. But what's the benefit of using trust
agents then?

Just that: when trust is established and you don't need anything to act
from AD DC side, use of trust agents reduces an attack surface as no
Samba services would be running on that system.

What I tried to accomplish was putting two IPA servers in the same
firewall zone as the windows AD DCs. Another two IPA servers reside
in the same zone where potential IPA clients are. Clients should
have communicated only with the IPA servers within the same zone.
(Of course, IPA servers could have communicated amongst each other)
- Am I right that there is no possibility of realizing such a
scenario? (because clients always need to be able to talk to the AD
DCs?)

There is no way to achieve that without IPA servers being able to talk
to AD DCs. You are right as well: clients must always be able to
talk to

AD DCs for authentication, e.g. Kerberos. This part can be routed via
KDC proxy on IPA server side, though but IPA server itself has to have
direct access to AD DCs.

IPA trust agents need to talk LDAP and Kerberos to AD DCs, IPA clients
only need to talk Kerberos to AD DCs and LDAP/Kebreros to IPA servers.

Could you briefly explain why Kerberos is needed? When I read
kerberos I always have passwordless login in mind. But isn't it used
somehow for password-based logins as well? (Do you know a source that
explains that without going too much into all the technical details?)
I need to know a little more about that...

SSSD for both 'ipa' and 'ad' providers requires Kerberos authentication.

If you are using Kerberos authentication to some front-facing
application, that is consumed by that application.

When you need to actually login to the system at a console, be it a
desktop or a terminal console, you would be asked to login with a
password. On IPA-enrolled systems that means using SSSD through a PAM
interface and provide a password. PAM module pam_sss will pass it
through to the SSSD backend and that one will initiate Kerberos
authentication using this password against a domain controller. There
are few cases when in IPA case SSSD might opt to LDAP authentication but
this is certainly not a normal setup.

If you want a not-so-technical source, I'd recommend reading Microsoft
Active Directory overview documents. This example from AD authentication
services protocols overview is describing a password-based login in AD
environment:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod/b221998b-242b-41ef-a116-891c73fd2410

The whole MS-AUTHSOD document is a great starting point.

What could be a solution for my scenario. Use a trust controller and
a trust agent in the same firewall zone as the Windows AD DCs? The
clients would only need to communicate to the AD DCS via Kerberos and
to the trust agent via LDAP and Kerberos, right?

Put IPA servers in the same firewall zone as the AD DCs. Configure your
IPA clients to use KDC proxy on IPA servers when talking to AD DCs.
Enable IPA clients to only talk to IPA servers.
Maybe it would be better to put one IPA server in the clients' FW zone
and let that particular server be a KDC proxy. Then I would only need to
setup communication through the FW between that IPA server and the
Windows DCs, right?

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

[Freeipa-users] Re: Trust-Agents

2023-01-17 Thread Ronald Wimmer via FreeIPA-users

On 17.01.23 10:07, Alexander Bokovoy wrote:

On ti, 17 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:

On 16.01.23 21:46, Alexander Bokovoy wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:

On 16.01.23 20:16, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:

On 16.01.23 15:48, Alexander Bokovoy via FreeIPA-users wrote:

The other two IPA servers can only talk to these IPA servers
and not to the AD DCs directly. Thats why I wanted them to have
the Trust Agent Role only.

Trust Agent also should be able to talk to AD DCs. If those servers
cannot talk to AD DCs, they cannot be trust agents.

So it seems that I have misunderstood how trust agents can be
used. I thought AD communication is only done on trust
controllers whereas trust agents are some kind of proxies.

services of AD DCs, not the other direction.

Thanks for clarifying that. But what's the benefit of using trust
agents then?

Just that: when trust is established and you don't need anything to act
from AD DC side, use of trust agents reduces an attack surface as no
Samba services would be running on that system.

There is no way to achieve that without IPA servers being able to talk
to AD DCs. You are right as well: clients must always be able to
talk to

AD DCs for authentication, e.g. Kerberos. This part can be routed via
KDC proxy on IPA server side, though but IPA server itself has to have
direct access to AD DCs.

IPA trust agents need to talk LDAP and Kerberos to AD DCs, IPA clients
only need to talk Kerberos to AD DCs and LDAP/Kebreros to IPA servers.

SSSD for both 'ipa' and 'ad' providers requires Kerberos authentication.

If you are using Kerberos authentication to some front-facing
application, that is consumed by that application.

The whole MS-AUTHSOD document is a great starting point.

Put IPA servers in the same firewall zone as the AD DCs. Configure your
IPA clients to use KDC proxy on IPA servers when talking to AD DCs.
Enable IPA clients to only talk to IPA servers.

Thanks a lot for taking the time to answer my questions! I do highly
appreciate that!

[Freeipa-users] Re: Trust-Agents

2023-01-17 Thread Ronald Wimmer via FreeIPA-users


On 16.01.23 21:46, Alexander Bokovoy wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:

On 16.01.23 20:16, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:



On 16.01.23 15:48, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:
I have a setup where we have four IPA servers. Two of them are 
able to talk to the AD Domain Controllers directly. I set them up 
as AD Trust controllers.


The other two IPA servers can only talk to these IPA servers and 
not to the AD DCs directly. Thats why I wanted them to have the 
Trust Agent Role only.


Trust Agent also should be able to talk to AD DCs. If those servers
cannot talk to AD DCs, they cannot be trust agents.


So it seems that I have misunderstood how trust agents can be used. 
I thought AD communication is only done on trust controllers whereas 
trust agents are some kind of proxies.


They aren't proxies but since they don't run DC services expected by
Active Directory domain controllers, they cannot be contacted by AD DCs
to perform normal LSA RPC calls. So they are agents in this sense: they
cannot participate in DC to DC communication with Active Directory DCs.
Identity resolution on agents is performed by SSSD which talks to LDAP
services of AD DCs, not the other direction.


Thanks for clarifying that. But what's the benefit of using trust 
agents then?


Just that: when trust is established and you don't need anything to act
from AD DC side, use of trust agents reduces an attack surface as no
Samba services would be running on that system.



What I tried to accomplish was putting two IPA servers in the same 
firewall zone as the windows AD DCs. Another two IPA servers reside in 
the same zone where potential IPA clients are. Clients should have 
communicated only with the IPA servers within the same zone. (Of 
course, IPA servers could have communicated amongst each other) - Am I 
right that there is no possibility of realizing such a scenario? 
(because clients always need to be able to talk to the AD DCs?)


There is no way to achieve that without IPA servers being able to talk
to AD DCs. You are right as well: clients must always be able to talk to
AD DCs for authentication, e.g. Kerberos. This part can be routed via
KDC proxy on IPA server side, though but IPA server itself has to have
direct access to AD DCs.

IPA trust agents need to talk LDAP and Kerberos to AD DCs, IPA clients
only need to talk Kerberos to AD DCs and LDAP/Kebreros to IPA servers.



Could you briefly explain why Kerberos is needed? When I read kerberos I 
always have passwordless login in mind. But isn't it used somehow for 
password-based logins as well? (Do you know a source that explains that 
without going too much into all the technical details?) I need to know a 
little more about that...


What could be a solution for my scenario. Use a trust controller and a 
trust agent in the same firewall zone as the Windows AD DCs? The clients 
would only need to communicate to the AD DCS via Kerberos and to the 
trust agent via LDAP and Kerberos, right?


Cheers,
Ronald
___
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: Trust-Agents

2023-01-16 Thread Ronald Wimmer via FreeIPA-users


On 16.01.23 20:16, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:



On 16.01.23 15:48, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:
I have a setup where we have four IPA servers. Two of them are able 
to talk to the AD Domain Controllers directly. I set them up as AD 
Trust controllers.


The other two IPA servers can only talk to these IPA servers and 
not to the AD DCs directly. Thats why I wanted them to have the 
Trust Agent Role only.


Trust Agent also should be able to talk to AD DCs. If those servers
cannot talk to AD DCs, they cannot be trust agents.


So it seems that I have misunderstood how trust agents can be used. I 
thought AD communication is only done on trust controllers whereas 
trust agents are some kind of proxies.


They aren't proxies but since they don't run DC services expected by
Active Directory domain controllers, they cannot be contacted by AD DCs
to perform normal LSA RPC calls. So they are agents in this sense: they
cannot participate in DC to DC communication with Active Directory DCs.
Identity resolution on agents is performed by SSSD which talks to LDAP
services of AD DCs, not the other direction.


Thanks for clarifying that. But what's the benefit of using trust agents 
then?


What I tried to accomplish was putting two IPA servers in the same 
firewall zone as the windows AD DCs. Another two IPA servers reside in 
the same zone where potential IPA clients are. Clients should have 
communicated only with the IPA servers within the same zone. (Of course, 
IPA servers could have communicated amongst each other) - Am I right 
that there is no possibility of realizing such a scenario? (because 
clients always need to be able to talk to the AD DCs?)


Cheers,
Ronald
___
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: Trust-Agents

2023-01-16 Thread Ronald Wimmer via FreeIPA-users




On 16.01.23 15:48, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 16 tammi 2023, Ronald Wimmer via FreeIPA-users wrote:
I have a setup where we have four IPA servers. Two of them are able to 
talk to the AD Domain Controllers directly. I set them up as AD Trust 
controllers.


The other two IPA servers can only talk to these IPA servers and not 
to the AD DCs directly. Thats why I wanted them to have the Trust 
Agent Role only.


Trust Agent also should be able to talk to AD DCs. If those servers
cannot talk to AD DCs, they cannot be trust agents.


So it seems that I have misunderstood how trust agents can be used. I 
thought AD communication is only done on trust controllers whereas trust 
agents are some kind of proxies.


I used "ipa-adtrust-install --add-agents" on these servers. After 
configuring the roles and finishing the setup I did a "ipa 
server-role-find" to check if the roles where set correctly. I found 
out that all four IPA servers do have the Trust Controller role. And 
here comes my question... why? Why have the two servers been added as 
trust controllers and not as agents only?


You should have ran 'ipa-adtrust-install --add-agents' on existing trust
controllers, not on agents-to-be. This is what documentation says you to
do.


Running 'ipa-adtrust-install --add-agents' seems to have no effect. When 
I run that command on an ipa server it still has the agent AND the 
controller rolle afterwards.


Cheers,
Ronald
___
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] Trust-Agents

2023-01-16 Thread Ronald Wimmer via FreeIPA-users

I have a setup where we have four IPA servers. Two of them are able to 
talk to the AD Domain Controllers directly. I set them up as AD Trust 
controllers.


The other two IPA servers can only talk to these IPA servers and not to 
the AD DCs directly. Thats why I wanted them to have the Trust Agent 
Role only.


I used "ipa-adtrust-install --add-agents" on these servers. After 
configuring the roles and finishing the setup I did a "ipa 
server-role-find" to check if the roles where set correctly. I found out 
that all four IPA servers do have the Trust Controller role. And here 
comes my question... why? Why have the two servers been added as trust 
controllers and not as agents only?


Cheers,
Ronald
___
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: Ensure that IPA user can be resolved upon SystemD-Unit start

2023-01-12 Thread Ronald Wimmer via FreeIPA-users

On 12.01.23 16:28, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

I do have a sytemd service unit that uses an IPA used. However, upon
reboot it seems that that particular IPA user is not available upon
start of that particular systemd service.

Using "After=sssd.service" is not sufficient.

What would you recommend in this case?
(I am looking for a reliable systemd solution and do not want to rely on
a script checking for a particular user with getent for example)

You may want to cross-post to the sssd-users list.

I'd try nss-user-lookup.target instead. According to systemd.special(7):

nss-user-lookup.target

Cheers,
Ronald
___
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] Ensure that IPA user can be resolved upon SystemD-Unit start

2023-01-12 Thread Ronald Wimmer via FreeIPA-users

I do have a sytemd service unit that uses an IPA used. However, upon 
reboot it seems that that particular IPA user is not available upon 
start of that particular systemd service.


Using "After=sssd.service" is not sufficient.

What would you recommend in this case?
(I am looking for a reliable systemd solution and do not want to rely on 
a script checking for a particular user with getent for example)


Cheers,
Ronald
___
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] Essential ports between IPA servers and clients

2023-01-10 Thread Ronald Wimmer via FreeIPA-users

Which Ports have to be open (on which side) in order to enable basic IPA 
functionality between IPA servers and clients. 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/index#prereq-ports-list 
states 80 and 443 as well as 389 and 636 - despite the use of StartTLS.


So which ports in the list could probably be omitted? (if we do not need 
Kerberos functionality in that particular setup)


Cheers,
Ronald
___
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: Grant sudo to users only on their own workstations

2022-12-23 Thread Ronald Wimmer via FreeIPA-users


On 22.12.22 23:26, Ranbir via FreeIPA-users wrote:

On Wed, 2022-12-21 at 09:09 +0100, Ronald Wimmer via FreeIPA-users
wrote:

This concept could easily be customized to allow a single user only
and
give it sudo permissions.


This sounds like there is at least some usage of python to interact
with IPA. I unfortunately do not know python and I don't really want to
learn it. We likely have python developers on staff that could do what
I need...if they have time for it.


You would just need a data source with some hostname/admin user-mapping. 
The rest is pretty easy. If you can find somebody with a little python 
knowledge feel free to contact me regarding this matter.


Cheers,
Ronald
___
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: Grant sudo to users only on their own workstations

2022-12-21 Thread Ronald Wimmer via FreeIPA-users


On 21.12.22 08:59, Alexander Bokovoy via FreeIPA-users wrote:

On ti, 20 joulu 2022, Ranbir wrote:

On Tue, 2022-12-20 at 08:22 +0200, Alexander Bokovoy via FreeIPA-users
wrote:

FreeIPA does not provide generation capabilities in itself. These
things
are specific to individual deployments and their logic is impossible
to
automate in a generic way without exposing some kind of a general
purpose language to express it. So we aren't going to implement this
when all you can do is to use ansible-freeipa to define your logic
and
actions already.


I don't understand why it would be so hard. I'll try to explain better
how it might work.

1. 700 users get workstations
2. we put all users into a "workstation" user group
3. an HBAC rule "allow_workstation" is created for the "workstation"
  user group to login using the Services sshd, sudo, su, and su-l,
  as well as an HBAC Service Group called gnome
4. In the host records for each of the workstations, we select which
  user is the "admin" for that workstation.
5. IPA creates internally a Sudo rule for the user and workstation
  pair that gives that user "admin" control (i.e. all commands
  allowed as root/anyone)

That's it. freeipa would be doing on its own and tracking internally
what we would have to do anyway via ansible or the web UI. Nothing
fancy or complicated. Why would this be difficult to support within
freeipa? I apologize if this is a dumb question. :P


This is not a dumb question, of course. ;) What you describe above is
pretty much what I said is a configuration specific to an individual
deployment. Can you implement an automation in FreeIPA for your use
case? Yes. Should it be implemented by FreeIPA upstream project? I would
say 'no'.

FreeIPA management middleware provides a pluggable core that can be
extended with plugins. Most of functionality you see in IPA CLI or
access over Web UI is provided by the plugins in IPA management
middleware. These plugins can be added externally, in absolute majority
of cases they do not require modifications of IPA core itself.

The plugins need to be written in Python. You can find some examples at
my github account: https://github.com/abbra. A plugin can also amend
actions of other plugins. This means you can add some sort of a plugin
that is run when an action is being done on a different object.

This gives a lot of flexibility that can be used to implement whatever
logic you want to create. However, there is no magic: someone have to
write down the steps to be performed and logically connect them to
actions that would trigger the operation in question.
A description of your requirements above cannot be connected to a
particular action. It looks like you have at least:

  - add a user to 'workstation' user group
  - select a user as an admin of the workstation

as two definitive actions to be performed before the rest of rules be
created. A workstation is a host but we have no concept of ownership of
hosts for users. There is a machine ownership by other machines ('ipa
host-add-managedby' command), but there is no way to tell that a
particular user 'owns' this machine in the host entry.

Hence, you cannot simply connect a user to machine and then trigger some
action. You would probably need to add some attribute in IPA to hold
this relationship 'user -> machine' which means a new plugin would need
to be created, new LDAP attribute allocated to store it, new commands
added to manage it, etc.

As I said, this all can be done. We did something similar when
integrating FleetCommander desktop management tool with FreeIPA and
SSSD: https://github.com/abbra/freeipa-desktop-profile, design document
is 
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki

This was to be able to provide an integrated solution which covered a
specific use case and spanned GNOME, FleetCommander, SSSD, FreeIPA, and
few other projects.

In the case of the FleetCommander's integration we did not need to
automatically create additional HBAC and SUDO rules. Those can be
created as a part of the plugin flow, of course, using internal IPA API.
Most of the API details are now published at
https://freeipa.readthedocs.io/en/latest/api/index.html but for writing
plugins you need to read FreeIPA's source code as well.

However, I do not think this should be part of IPA itself.
FleetCommander plugin, for example, is maintained separately without any
problems. There are other plugins written by different people and
different organizations and not all of them are known to FreeIPA
developers -- we only get to know about stuff that being published
somewhere and asked about on these mailing lists or in an issue tracker.

Now, if you have no people at your organization to implement a plugin to
provide an integrated solution, you can write down the logic you need to
create all additional rules in ansible-freeipa playbooks. This gives a
better way to preserve the logic for administrators and run these
playbooks whenever

[Freeipa-users] Re: Max number of users

2022-12-15 Thread Ronald Wimmer via FreeIPA-users


On 15.12.22 11:09, None via FreeIPA-users wrote:

Hello,
what is the maximum number of users you can add to freeipa?


The only limit I am aware of are the ID and DNA ranges.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/adjusting-id-ranges-manually_configuring-and-managing-idm

cheers,
Ronald
___
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: Microsoft November 2022 updates breaks Active Directory integration

2022-11-14 Thread Ronald Wimmer via FreeIPA-users


On 14.11.22 16:19, Rob Crittenden via FreeIPA-users wrote:

Microsoft addressed a number of CVEs last week which introduced some
authentication issues. After installation of these patches, user
authentication on Linux systems integrated in Active Directory no longer
works and new systems are unable to join an AD domain that is managed by
domain controllers where these patches have been applied.

For more details see https://access.redhat.com/solutions/6985061 (open
to the public).


Thanks a lot for the info!

Cheers,
Ronald
___
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: LoadBalancer vs. DNS

2022-11-06 Thread Ronald Wimmer via FreeIPA-users


On 04.11.22 17:40, Brendan Kearney via FreeIPA-users wrote:

unicast is one-to-one
anycast is one-to-one-of-many


Thats the best brief but most precise explanation I've heard for a long 
time!


Cheers,
Ronald
___
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: IPA API - Fetch keytab

2022-11-06 Thread Ronald Wimmer via FreeIPA-users


On 04.11.22 17:47, Jochen Kellner wrote:

Ronald Wimmer via FreeIPA-users 
writes:


Jochen already provided you the required commands. They can be
automated
easily.


I was still thinking about how to do that from the AIX side. I'm
sorry... Obviously I could need more coffee. ;-)


A lot of what can be done depends on what you use as AIX automation. If
you still use shell scripts - ssh to a linux host is your most likely
solution.  If you use something like ansible, you might want to check
"delegate_to" in the ansible documentation. In the unlikely event you
use SALT, have a look at orchestration. For other tool I declare total
ignorance.


We will go the shell script way as not many AIX hosts look the same and 
Ansible might be a problem. The IPA client host will most likely be a 
K8s pod - maybe even without persistent storage. I'll have to check with 
the IPA developers if a ephemeral IPA clients will eat up id ranges or 
else over time.

There are lots and lots of possible solutions.

Just a hint how you might handle authentication for IPA commands: Add a
user to IPA that has the role "Enrollment Administrator". Get a keytab
for that user and store it at a save place on your IPA client. You
should be able to run "ipa" and other commands with and not giving
name/password on the command line:
   env KRB5_CLIENT_KTNAME=/path/to/key.tab ipa ...


Thanks. I am using this already somewhere else.


(you might need to install urllib-gssapi or python3-urllib-gssapi)

That would still need some experimenting, but I'm sure it will work in
the end.


The first idea is to ssh to the Linux machine to call a python script 
doing all the magic and scp the keytab over to the AIX host.



Remember that the AIX host and freeipa need to agree what's the last
kvno is - That might be a problem while experimenting.


Thanks! I'll keep that in mind!

Cheers,
Ronald
___
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

1 2 3 4 5 >

1 - 100 of 416 matches

Mail list logo