Re: [Freeipa-users] Adjusting nsslapd-cachememsize

[Rich Megginson]

On 03/20/2017 03:14 PM, Lachlan Musicman wrote:
Directly editing the lse.ldif didn't work. ipactl start hangs on 
pki-tomcatd. I think I've broken it. I seem to recall ldap not liking 
being edited by hand.


You have to make sure dirsrv is not running before you edit dse.ldif.  
Not sure if ipactl stop will wait until all services are not running.




cheers
L.

--
The most dangerous phrase in the language is, "We've always done it 
this way."


- Grace Hopper

On 17 March 2017 at 19:45, Bob Hinton > wrote:


Hi Lachlan,

This is probably a complete hack, but the way I've changed
nsslapd-cachememsize in the past is -

On each ipa replica in turn -

 1. ipactl stop
 2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif- (where DOMAIN is
your server's domain/realm - not sure which) find and change
the value of nsslapd-cachememsize
 3. ipactl start

This seemed to work in that it made the error messages go away and
it made heavily loaded servers more stable. However, I've not
tried this on a recent version of ipa so it may no longer work or
not be needed any more.

Regards

Bob


On 17/03/2017 02:20, Lachlan Musicman wrote:

While going through the logs on the FreeIPA server, I noticed this:


WARNING: changelog: entry cache size 2097152 B is less than db
size 12804096 B; We recommend to increase the entry cache size
nsslapd-cachememsize.


I have found a number of documents:

What it is:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html



How to tune it:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html




etc etc.

I have no idea of what the secret password is for the
"cn=directory manager" and can't find any information about where
I might find it or where or when it might have been set anywhere.
I have found a number of likely candidates, but none have worked.

I found this page:

https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password


but I'd prefer to not change the password if possible.

cheers
L.



--
The most dangerous phrase in the language is, "We've always done
it this way."

- Grace Hopper









--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Adjusting nsslapd-cachememsize

[Lachlan Musicman]

Directly editing the lse.ldif didn't work. ipactl start hangs on
pki-tomcatd. I think I've broken it. I seem to recall ldap not liking being
edited by hand.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 17 March 2017 at 19:45, Bob Hinton  wrote:

> Hi Lachlan,
>
> This is probably a complete hack, but the way I've changed
> nsslapd-cachememsize in the past is -
>
> On each ipa replica in turn -
>
>1. ipactl stop
>2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif- (where DOMAIN is your
>server's domain/realm - not sure which) find and change the value of
>nsslapd-cachememsize
>3. ipactl start
>
> This seemed to work in that it made the error messages go away and it made
> heavily loaded servers more stable. However, I've not tried this on a
> recent version of ipa so it may no longer work or not be needed any more.
>
> Regards
>
> Bob
>
> On 17/03/2017 02:20, Lachlan Musicman wrote:
>
> While going through the logs on the FreeIPA server, I noticed this:
>
>
> WARNING: changelog: entry cache size 2097152 B is less than db size
> 12804096 B; We recommend to increase the entry cache size
> nsslapd-cachememsize.
>
>
> I have found a number of documents:
>
> What it is: https://access.redhat.com/documentation/en-US/Red_Hat_
> Directory_Server/8.0/html/Configuration_and_Command_
> Reference/Configuration_Command_File_Reference-Database_Attributes_under_
> cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_
> database_cnplugins_cnconfig-nsslapd_cachememsize.html
>
> How to tune it: https://access.redhat.com/documentation/en-US/Red_Hat_
> Directory_Server/8.1/html/Administration_Guide/memoryusage.html
>
>
> etc etc.
>
> I have no idea of what the secret password is for the "cn=directory
> manager" and can't find any information about where I might find it or
> where or when it might have been set anywhere. I have found a number of
> likely candidates, but none have worked.
>
> I found this page:
>
> https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
>
> but I'd prefer to not change the password if possible.
>
> cheers
> L.
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Alexander Bokovoy]

On ma, 20 maalis 2017, Iulian Roman wrote:

On Mon, Mar 20, 2017 at 4:24 PM, Alexander Bokovoy 
wrote:


On ma, 20 maalis 2017, Iulian Roman wrote:


On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy 
wrote:

On ma, 20 maalis 2017, Iulian Roman wrote:


Hello,


I noticed that nested group feature do not work with the unix ldap
clients
(AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used.
If
i use the cn=compat and change the mapping the nested groups are listed
properly.

Compat tree implements RFC2307 schema which doesn't have nested groups.


Correct, but although the groups under the compat tree do not have the

nestedgroup object class attribute, whenever i change the group membership
via WEB UI, the compat tree group membership is automatically updated (new
memberUid is added). What i've done was a sort of workaround and map the
AIX groups attribute to the memberUid which seems to work properly.


memberUid is uidNumber of corresponding user, not a group identifier.
Perhaps, you are trying to explain something else?


Ok, maybe i have to explain it more clearly as it was confusing:
in order to get the user list attribute for an ldap group in AIX , you use
some .map files, which map the ldap attributes to the AIX attributes. For
the 2307schema, to get the user list of a group you have to map the
AIX *_users_
*attribute to the _memberuid_ ldap attribute. For compat tree, in the file
ipagroup.map i've mapped the AIX _users_ attribute to the _memberuid_
ipa/ldap attribute and therefore i have the list of the users for that
particular group.  Having the user list which are members to a group
translates to having the group list of the users (if we invert the logic).
Does that make more sense now ?


According to my research from several years ago following two maps were
enough to get AIX to work with primary IPA tree:

#IPAuser.map file
keyobjectclass  SEC_CHARposixaccounts

# The following attributes are required by AIX to be functional
usernameSEC_CHARuid s
id  SEC_INT uidnumber   s
pgrpSEC_CHARgidnumber   s
homeSEC_CHARhomedirectory   s
shell   SEC_CHARloginshell  s
gecos   SEC_CHARgecos   s
spassword   SEC_CHARuserpasswords
lastupdate  SEC_INT shadowlastchanges

#IPAgroup.map file
groupname   SEC_CHARcns
id  SEC_INT gidNumber s
users   SEC_LISTmemberm

This will make AIX to interpret native IPA users properly.

If you expect AD users from trusted AD domains to be usable as well,
you'd need to switch to compat tree and use RFC2307 mapping files.


Why you don't use compat tree for both users and groups in AIX? This is
how it was designed to be used.


Actually the compat tree was the default one configured by the ldap client,
but checking the ldap structure seemed more logical to use the default ipa
ldap tree which is used as well for Linux. Moreover i did not understood
what is exactly the purpose of the compat tree and i was quite confused .
Apart from that i missed  some krb* related attributes for the user, but
probably i have to re-evaluate that and use compat tree for both users and
groups, if that's what it was designed for.

It depends on what you need to do. You shouldn't need to have access to
kerberos attributes from client side at all.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] ldap connector from IIQ to ipa

[Iulian Roman]

Hello,

We do plan to integrate  IPA with IdentityIQ (sailpoint) for user
provisioning. Because IPA does abstract all the ldap commands via new set
of commands and APIs, i am not sure if the standard ldap connector is the
right option and if it is supported ( taking into consideration that a
simple user creation does update/create more ldap containers).

Could you please clarify if updating IPA via standard ldap commands is
supported but not necessarily a best practice or it is an absolute NO ?

Thank You !
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Iulian Roman]

On Mon, Mar 20, 2017 at 4:24 PM, Alexander Bokovoy 
wrote:

> On ma, 20 maalis 2017, Iulian Roman wrote:
>
>> On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy 
>> wrote:
>>
>> On ma, 20 maalis 2017, Iulian Roman wrote:
>>>
>>> Hello,

 I noticed that nested group feature do not work with the unix ldap
 clients
 (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used.
 If
 i use the cn=compat and change the mapping the nested groups are listed
 properly.

 Compat tree implements RFC2307 schema which doesn't have nested groups.
>>>
>>> Correct, but although the groups under the compat tree do not have the
>> nestedgroup object class attribute, whenever i change the group membership
>> via WEB UI, the compat tree group membership is automatically updated (new
>> memberUid is added). What i've done was a sort of workaround and map the
>> AIX groups attribute to the memberUid which seems to work properly.
>>
> memberUid is uidNumber of corresponding user, not a group identifier.
> Perhaps, you are trying to explain something else?
>
Ok, maybe i have to explain it more clearly as it was confusing:
in order to get the user list attribute for an ldap group in AIX , you use
some .map files, which map the ldap attributes to the AIX attributes. For
the 2307schema, to get the user list of a group you have to map the
AIX *_users_
*attribute to the _memberuid_ ldap attribute. For compat tree, in the file
ipagroup.map i've mapped the AIX _users_ attribute to the _memberuid_
ipa/ldap attribute and therefore i have the list of the users for that
particular group.  Having the user list which are members to a group
translates to having the group list of the users (if we invert the logic).
Does that make more sense now ?

>
> Main tree in FreeIPA uses RFC2307bis schema which supports nested
>>> groups.
>>>
>>> Any plans to support RFC2307AIX schema ?
>>
> No.
>
>
>> On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX
>>> schemas. AIX's automounter does support RFC2307bis automount maps but
>>> the rest of the system does not support RFC2307bis. In particular, AIX
>>> does not understand member attribute  dereference.
>>>
>>>
>>> My question is if it is allowed to mix the compat and accounts cn for the
>>>
 userbasedn and groupbasedn on the same unix ldap client ?

 No, not really. You are messing it up something that your client
>>> does not understand.
>>>
>>> As i explained above, i could use the basic attributes in the compat tree
>> for groups in order to update the AIX "groups" attribute (based on
>> memberuid list). Is there anything which can break the functionality if
>> the
>> compat tree is used instead of the main/accounts tree  or it is a
>> fortunate
>> coincidence that this setup works ?
>>
> Why you don't use compat tree for both users and groups in AIX? This is
> how it was designed to be used.
>
Actually the compat tree was the default one configured by the ldap client,
but checking the ldap structure seemed more logical to use the default ipa
ldap tree which is used as well for Linux. Moreover i did not understood
what is exactly the purpose of the compat tree and i was quite confused .
Apart from that i missed  some krb* related attributes for the user, but
probably i have to re-evaluate that and use compat tree for both users and
groups, if that's what it was designed for.


>
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Use SQLite format NSS database?

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 20.03.2017 16:12, Ian Pilcher wrote:
>> On 03/20/2017 04:00 AM, David Kupka wrote:
>>> Generally I would not recommend touching this on production system.
>>> Why do you want to change the database format?
>>
>> My FreeIPA server also acts as a reverse proxy/TLS endpoint for my
>> home sprinkler system (https://opensprinkler.com/), allowing me to
>> securely connect to the sprinkler controller from my cell phone when
>> I'm out in the yard (out of WiFi range).
>>
>> Since free 1-year TLS certificates seem to be a thing of the past, I'm
>> working on automating the retrieval of 90-day certificates from Let's
>> Encrypt.
>>
>> My current update script has to stop Apache before updating the
>> certificate in the NSS database.  It's hardly the end of the world, but
>> it would have been nice to be able to load the new certificate into the
>> database and just send a SIGHUP to the daemon.
>>
> 
> Might this help for Lets encrypt ?
> https://github.com/freeipa/freeipa-letsencrypt

I think his concern may be around warnings that the NSS BDB databases
should only be updated when quiet. In the case of mod_nss it explicitly
opens the database read-only so I think you'd be safe updating the
certificate.

A SIGHUP may indeed be sufficient to load the new cert, just haven't had
a chance to test it this morning.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Use SQLite format NSS database?

[Martin Basti]

On 20.03.2017 16:12, Ian Pilcher wrote:
> On 03/20/2017 04:00 AM, David Kupka wrote:
>> Generally I would not recommend touching this on production system.
>> Why do you want to change the database format?
>
> My FreeIPA server also acts as a reverse proxy/TLS endpoint for my
> home sprinkler system (https://opensprinkler.com/), allowing me to
> securely connect to the sprinkler controller from my cell phone when
> I'm out in the yard (out of WiFi range).
>
> Since free 1-year TLS certificates seem to be a thing of the past, I'm
> working on automating the retrieval of 90-day certificates from Let's
> Encrypt.
>
> My current update script has to stop Apache before updating the
> certificate in the NSS database.  It's hardly the end of the world, but
> it would have been nice to be able to load the new certificate into the
> database and just send a SIGHUP to the daemon.
>

Might this help for Lets encrypt ?
https://github.com/freeipa/freeipa-letsencrypt

Martin



signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Alexander Bokovoy]

On ma, 20 maalis 2017, Lukas Slebodnik wrote:

On (20/03/17 17:00), Alexander Bokovoy wrote:

On ma, 20 maalis 2017, Iulian Roman wrote:

Hello,

I noticed that nested group feature do not work with the unix ldap clients
(AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If
i use the cn=compat and change the mapping the nested groups are listed
properly.

Compat tree implements RFC2307 schema which doesn't have nested groups.

Main tree in FreeIPA uses RFC2307bis schema which supports nested
groups.


But "Compat tree" is generated from "Main tree".
Therefore users must have the same groups in both cases.

They are, for POSIX groups. RFC2307bis allows you to have arbitrary
nested groups, RFC2307 only handles POSIX groups.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Iulian Roman]

On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy 
wrote:

> On ma, 20 maalis 2017, Iulian Roman wrote:
>
>> Hello,
>>
>> I noticed that nested group feature do not work with the unix ldap clients
>> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used.
>> If
>> i use the cn=compat and change the mapping the nested groups are listed
>> properly.
>>
> Compat tree implements RFC2307 schema which doesn't have nested groups.
>
Correct, but although the groups under the compat tree do not have the
nestedgroup object class attribute, whenever i change the group membership
via WEB UI, the compat tree group membership is automatically updated (new
memberUid is added). What i've done was a sort of workaround and map the
AIX groups attribute to the memberUid which seems to work properly.


> Main tree in FreeIPA uses RFC2307bis schema which supports nested
> groups.
>
> Any plans to support RFC2307AIX schema ?

> On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX
> schemas. AIX's automounter does support RFC2307bis automount maps but
> the rest of the system does not support RFC2307bis. In particular, AIX
> does not understand member attribute  dereference.
>
>
> My question is if it is allowed to mix the compat and accounts cn for the
>> userbasedn and groupbasedn on the same unix ldap client ?
>>
> No, not really. You are messing it up something that your client
> does not understand.
>
As i explained above, i could use the basic attributes in the compat tree
for groups in order to update the AIX "groups" attribute (based on
memberuid list). Is there anything which can break the functionality if the
compat tree is used instead of the main/accounts tree  or it is a fortunate
coincidence that this setup works ?

>
>
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Alexander Bokovoy]

On ma, 20 maalis 2017, Iulian Roman wrote:

On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy 
wrote:


On ma, 20 maalis 2017, Iulian Roman wrote:


Hello,

I noticed that nested group feature do not work with the unix ldap clients
(AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used.
If
i use the cn=compat and change the mapping the nested groups are listed
properly.


Compat tree implements RFC2307 schema which doesn't have nested groups.


Correct, but although the groups under the compat tree do not have the
nestedgroup object class attribute, whenever i change the group membership
via WEB UI, the compat tree group membership is automatically updated (new
memberUid is added). What i've done was a sort of workaround and map the
AIX groups attribute to the memberUid which seems to work properly.

memberUid is uidNumber of corresponding user, not a group identifier.
Perhaps, you are trying to explain something else?


Main tree in FreeIPA uses RFC2307bis schema which supports nested
groups.


Any plans to support RFC2307AIX schema ?

No.




On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX
schemas. AIX's automounter does support RFC2307bis automount maps but
the rest of the system does not support RFC2307bis. In particular, AIX
does not understand member attribute  dereference.


My question is if it is allowed to mix the compat and accounts cn for the

userbasedn and groupbasedn on the same unix ldap client ?


No, not really. You are messing it up something that your client
does not understand.


As i explained above, i could use the basic attributes in the compat tree
for groups in order to update the AIX "groups" attribute (based on
memberuid list). Is there anything which can break the functionality if the
compat tree is used instead of the main/accounts tree  or it is a fortunate
coincidence that this setup works ?

Why you don't use compat tree for both users and groups in AIX? This is
how it was designed to be used.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Access issue

[Lukas Slebodnik]

On (20/03/17 16:39), Alexander Bokovoy wrote:
>On ma, 20 maalis 2017, Artem Golubev wrote:
>> Good day!
>> 
>> We use freeipa server 4.3.1, we usually grant access via ssh keys to linux
>> clients.
>> We currently face the following issue with access on certificate: when we
>> add certificate to user's account, user is not able to login via ssh.
>> How can we solve this problem? We would like to have  a possibility to
>> access linux clients via ssh keys and access to other resources using
>> certificates.
>You need to provide logs, obviously. Start with level 3 debug logs in
>sshd, and debug_level=9 in sssd. Also show user's entry (as in 'ipa
>user-show --raw --all username').
>
>When you access SSH with ssh keys, SSSD is involved in account and
>session phases of PAM authentication. This means either user does not
>exist to sshd (it would then don't exist on system level at all) or
>something prevents session phase from success. In session phase SSSD
>does verify HBAC rules, for example.
>
>See https://fedorahosted.org/sssd/wiki/Troubleshooting for
>troubleshooting instructions.
>
The most important is to know version of sssd.
Because one related bug is already fixed.
https://pagure.io/SSSD/sssd/issue/2977

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Use SQLite format NSS database?

[Ian Pilcher]

On 03/20/2017 04:00 AM, David Kupka wrote:

Generally I would not recommend touching this on production system.
Why do you want to change the database format?


My FreeIPA server also acts as a reverse proxy/TLS endpoint for my
home sprinkler system (https://opensprinkler.com/), allowing me to
securely connect to the sprinkler controller from my cell phone when
I'm out in the yard (out of WiFi range).

Since free 1-year TLS certificates seem to be a thing of the past, I'm
working on automating the retrieval of 90-day certificates from Let's
Encrypt.

My current update script has to stop Apache before updating the
certificate in the NSS database.  It's hardly the end of the world, but
it would have been nice to be able to load the new certificate into the
database and just send a SIGHUP to the daemon.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Access issue

[Sumit Bose]

On Mon, Mar 20, 2017 at 02:55:37PM +0300, Artem Golubev wrote:
> Good day!
> 
> We use freeipa server 4.3.1, we usually grant access via ssh keys to linux
> clients.
> We currently face the following issue with access on certificate: when we
> add certificate to user's account, user is not able to login via ssh.
> How can we solve this problem? We would like to have  a possibility to
> access linux clients via ssh keys and access to other resources using
> certificates.

I guess this is https://pagure.io/SSSD/sssd/issue/2977 which should be
fixed in recent version of SSSD. Which version of SSSD are you using and
which platform/OS?

HTH

bye,
Sumit

> 
> Hope to receive a reply from you soon.
> Best regards.
> *​*
> 
> *​Artem Golubev*
> System Administrator
> *(exp)capital limited*

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Lukas Slebodnik]

On (20/03/17 17:00), Alexander Bokovoy wrote:
>On ma, 20 maalis 2017, Iulian Roman wrote:
>> Hello,
>> 
>> I noticed that nested group feature do not work with the unix ldap clients
>> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If
>> i use the cn=compat and change the mapping the nested groups are listed
>> properly.
>Compat tree implements RFC2307 schema which doesn't have nested groups.
>
>Main tree in FreeIPA uses RFC2307bis schema which supports nested
>groups.
>
But "Compat tree" is generated from "Main tree".
Therefore users must have the same groups in both cases.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] compat and nested groups for Unix system

[Alexander Bokovoy]

On ma, 20 maalis 2017, Iulian Roman wrote:

Hello,

I noticed that nested group feature do not work with the unix ldap clients
(AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If
i use the cn=compat and change the mapping the nested groups are listed
properly.

Compat tree implements RFC2307 schema which doesn't have nested groups.

Main tree in FreeIPA uses RFC2307bis schema which supports nested
groups.

On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX
schemas. AIX's automounter does support RFC2307bis automount maps but
the rest of the system does not support RFC2307bis. In particular, AIX
does not understand member attribute  dereference.



My question is if it is allowed to mix the compat and accounts cn for the
userbasedn and groupbasedn on the same unix ldap client ?

No, not really. You are messing it up something that your client
does not understand.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] compat and nested groups for Unix system

[Iulian Roman]

Hello,

I noticed that nested group feature do not work with the unix ldap clients
(AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If
i use the cn=compat and change the mapping the nested groups are listed
properly.

My question is if it is allowed to mix the compat and accounts cn for the
userbasedn and groupbasedn on the same unix ldap client ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Access issue

[Alexander Bokovoy]

On ma, 20 maalis 2017, Artem Golubev wrote:

Good day!

We use freeipa server 4.3.1, we usually grant access via ssh keys to linux
clients.
We currently face the following issue with access on certificate: when we
add certificate to user's account, user is not able to login via ssh.
How can we solve this problem? We would like to have  a possibility to
access linux clients via ssh keys and access to other resources using
certificates.

You need to provide logs, obviously. Start with level 3 debug logs in
sshd, and debug_level=9 in sssd. Also show user's entry (as in 'ipa
user-show --raw --all username').

When you access SSH with ssh keys, SSSD is involved in account and
session phases of PAM authentication. This means either user does not
exist to sshd (it would then don't exist on system level at all) or
something prevents session phase from success. In session phase SSSD
does verify HBAC rules, for example.

See https://fedorahosted.org/sssd/wiki/Troubleshooting for
troubleshooting instructions.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] upgrade ipa-server fails changing dogtag key

[Andrew E. Bruno]

When yum updating our ipa-server running CentOS 7.3.1611 from
ipa-server-4.4.0-14.el7.centos.1.1.x86_64 to
ipa-server-4.4.0-14.el7.centos.6.x86_64 we got this error:


IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command 
ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
OSError: [Errno 2] No such file or directory: 
'/etc/pki/pki-tomcat/dogtag.keytab'
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more 
information

Inspecting /var/log/ipaupgrade.log shows this error:


2017-03-20T12:58:41Z DEBUG Process finished, return code=0
2017-03-20T12:58:41Z DEBUG stdout=Authenticating as principal root/admin@REALM 
with password.

2017-03-20T12:58:41Z DEBUG stderr=kadmin.local: Server error while changing 
dogtag/host@REAM's key

2017-03-20T12:58:41Z ERROR IPA server upgrade failed: Inspect 
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2017-03-20T12:58:41Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute
return_value = self.run()
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", 
line 46, in run
server.upgrade()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", 
line 1863, in upgrade
upgrade_configuration()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", 
line 1796, in upgrade_configuration
ca.setup_lightweight_ca_key_retrieval()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 
1400, in setup_lightweight_ca_key_retrieval
self.__setup_lightweight_ca_key_retrieval_kerberos()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 
1431, in __setup_lightweight_ca_key_retrieval_kerberos
os.chmod(keytab, 0o600)

2017-03-20T12:58:41Z DEBUG The ipa-server-upgrade command failed, exception: 
OSError: [Errno 2] No such file or directory: 
'/etc/pki/pki-tomcat/dogtag.keytab'


The ipa services came back up (kinit is working and can login to the console).
This seems related to [1,2]. Checked to ensure that dogtag service points to
the default service password policy per [1]:

$ ipa service-show --all dogtag/host

  krbpwdpolicyreference: cn=Default Service Password 
Policy,cn=services,cn=accounts,dc=REALM

However when listing all the pwpolicies this doesn't seem to exist anywhere? We
only have a single global pwpolicy:

$ ipa pwpolicy-find
  Group: global_policy

Number of entries returned 1


Could this be related to the error? Any pointers on how to trouble shoot?

Thanks in advance.

--Andrew


[1] https://www.redhat.com/archives/freeipa-users/2017-March/msg00178.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1404910

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Certificate Access issue

[Artem Golubev]

Good day!

We use freeipa server 4.3.1, we usually grant access via ssh keys to linux
clients.
We currently face the following issue with access on certificate: when we
add certificate to user's account, user is not able to login via ssh.
How can we solve this problem? We would like to have  a possibility to
access linux clients via ssh keys and access to other resources using
certificates.

Hope to receive a reply from you soon.
Best regards.
*​*

*​Artem Golubev*
System Administrator
*(exp)capital limited*
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Errors in IPA logs

[Lachlan Musicman]

On 20 March 2017 at 19:38, Martin Basti  wrote:

> On 19.03.2017 22:58, Lachlan Musicman wrote:
>
> Hi,
>
> I've reported a bug against SSSD and Lukas has pointed to a number of
> FreeIPA errors in our logs.
> I've can't find any information on how I might fix these errors or what I
> might do to mitigate them. Any pointers appreciated:
>
> First error:
>
> [sssd[be[unixdev.domain.org.au]]] [ipa_sudo_fetch_rules_done] (0x0040):
> Received 1 sudo rules
>
> [sssd[be[unixdev.domain.org.au]]] [sysdb_mod_group_member] (0x0080):
> ldb_modify failed: [No such attribute](16)[attribute 'member': no matching
> attribute value while deleting attribute on 'name=ipa_bioinf_staff@
> unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb']
>
> [sssd[be[unixdev.domain.org.au]]] [sysdb_error_to_errno] (0x0020): LDB
> returned unexpected error: [No such attribute]
>
> [sssd[be[unixdev.domain.org.au]]] [sysdb_update_members_ex] (0x0020):
> Could not remove member [simpsonlach...@domain.org.au] from group [name=
> ipa_bioinf_st...@unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb].
> Skipping
>
>
>
> Second error is long list of errors that look like
>
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second component,
> got OU
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second component,
> got Users
>
>
> I don't know enough about AD to speak meaningfully to these, but a quick
> google shows that a group can have cn=Users as it's second component ( see
> here for example https://technet.microsoft.com/
> en-us/library/dn579255%28v=ws.11%29.aspx )
>
> Is there an LDAP query that I need to define or add to the IPA server?
>
> cheers
> L.
>
>
> Hello,
>
> can you describe your deployment more? Your DNs doesn't look like created
> by FreeIPA
> This is not how FreeIPA's DIT looks 'name=ipa_bioinf_staff@
> unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb'
>


DNS isn't done by FreeIPA - it's all in AD. With a one way trust and all
users and groups managed by AD - except for overrides and external groups
for HBAC - everything is in AD.

As for the FreeIPA DIT - that is a group created in FreeIPA (through the
GUI iirc). I haven't done anything particularly special to make it look
like that (with the domain inside the cn). Unless it's a strange confluence
of configurations that has created a situation that would make that happen.

cheers
L.

So, wrt to your question, what can I give you/what were you after?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Use SQLite format NSS database?

[David Kupka]

On Sat, Mar 18, 2017 at 11:58:35AM -0500, Ian Pilcher wrote:
> Can IPA 4.4 (on CentOS 7) use a SQLite format NSS database in
> /etc/httpd/alias?
> 
> I would presumably have to prepend "sql:" to the NSSCertificateDatabase
> setting in nss.conf.
> 
> Anything else?
> 
> -- 
> 
> Ian Pilcher arequip...@gmail.com
>  "I grew up before Mark Zuckerberg invented friendship" 
> 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

Hello Ian,
I'm not sure but I guess there will be surprises on the way.

First of all you need to migrate the DB to SQL format (1). Then you will have
two DBs in alias directory one in old and one in new format. This is probably
not what you want because then you can easily end up with two different sets of
certificates and hard to find errors. So it's probably better to remove old DB
(cert8.db, key3.db and secmod.db). But then you'll break ipa-certupdate,
ipa-server-certinstall and probably others because they use the old format.
Prefixing 'sql:' to HTTPD_ALIAS_DIR in
/usr/lib/ptyhon2.7/site-packages/ipaplatform/base/paths.py might help but I
never tried.

Generally I would not recommend touching this on production system. Why do you
want to change the database format?

(1) certutil -d sql:HTTPD_ALIAS_DIR --upgrade-merge --source-dir
HTTPD_ALIAS_DIR --upgrade-id 1

-- 
David Kupka


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Errors in IPA logs

[Martin Basti]

On 19.03.2017 22:58, Lachlan Musicman wrote:
> Hi,
>
> I've reported a bug against SSSD and Lukas has pointed to a number of
> FreeIPA errors in our logs.
> I've can't find any information on how I might fix these errors or
> what I might do to mitigate them. Any pointers appreciated:
>
> First error:
>
> [sssd[be[unixdev.domain.org.au ]]]
> [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules
>
> [sssd[be[unixdev.domain.org.au ]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> attribute](16)[attribute 'member': no matching attribute value while
> deleting attribute on 'name=ipa_bioinf_st...@unixdev.domain.org.au
> ,cn=groups,cn=unixdev.domain.org.au
> ,cn=sysdb']
>
> [sssd[be[unixdev.domain.org.au ]]]
> [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No
> such attribute]
>
> [sssd[be[unixdev.domain.org.au ]]]
> [sysdb_update_members_ex] (0x0020): Could not remove member
> [simpsonlach...@domain.org.au ]
> from group [name=ipa_bioinf_st...@unixdev.domain.org.au
> ,cn=groups,cn=unixdev.domain.org.au
> ,cn=sysdb]. Skipping
>
>
>
> Second error is long list of errors that look like
>
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second
> component, got OU
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second
> component, got Users
>
>
> I don't know enough about AD to speak meaningfully to these, but a
> quick google shows that a group can have cn=Users as it's second
> component ( see here for example
> https://technet.microsoft.com/en-us/library/dn579255%28v=ws.11%29.aspx )
>
> Is there an LDAP query that I need to define or add to the IPA server?
>
> cheers
> L.
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it
> this way."
>
> - Grace Hopper
>
>


Hello,

can you describe your deployment more? Your DNs doesn't look like
created by FreeIPA
This is not how FreeIPA's DIT looks
'name=ipa_bioinf_st...@unixdev.domain.org.au
,cn=groups,cn=unixdev.domain.org.au
,cn=sysdb'

Martin


signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] shadow netgroups with wrong domains - sudo problem [SOLVED]

[Bob Hinton]

On 20/03/2017 08:29, Jakub Hrozek wrote:
> On Fri, Mar 17, 2017 at 01:52:17PM +, Bob Hinton wrote:
>> On 17/03/2017 12:48, Lukas Slebodnik wrote:
>>> On (17/03/17 10:40), Bob Hinton wrote:
 On 17/03/2017 08:41, Jakub Hrozek wrote:
> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
>> Morning,
>>
>> We have a collection of hosts within prod1.local.lan. However, the
>> domain section of the shadow netgroups for the hosts is
>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these
>> hosts unless they specify all hosts -
>>
>> -sh-4.2$ getent netgroup oepp_hosts
>> oepp_hosts   
>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>> -sh-4.2$ hostname
>> oeppredis001.z4.prod1.local.lan
>> -sh-4.2$ nisdomainname
>> local.lan
>> -sh-4.2$ domainname
>> local.lan
>>
>> The VMs associated with these hosts have recently been migrated and
>> re-enrolled against a new IPA server. The originals all had netgroup
>> domains of local.lan so something must have gone wrong in the migration
>> process. Is there a way to correct the netgroup domains of these hosts,
>> or is the only option to run ipa-client-install --uninstall followed by
>> ipa-client-install to reattach them ?
> Did you remove the sssd cache after the migration?
> rm -f /var/lib/sss/db/*.ldb
>
> (please make sure the clients can reach the server or maybe mv the cache
> instead of rm so you can restore cached credentials if something goes
> wrong..)
>
 Hi Jakub,

 I've now tried removing the sssd cache on one of the offending servers
 and it's not made any difference.

 getent netgroup oepp_hosts

 when run from any host enrolled to the new IPA servers, including the
 IPA masters themselves produces the results with "mgmt.prod" included
 and the same thing run on any of the pre-migrated servers that are still
 commissioned produces them without, so I assume that the netgroup domain
 information is coming from the IPA masters rather than the local host.

>>> Could you provide content of LDIF from IPA server?
>>> For this netgroup/hostgroup
>>>
>>> LS
>> Hi Jakub,
>>
>> I extracted the following from the userRoot ldif produced by "ipa-backup
>> --data".
>>
>> It appears to have the incorrect domain set against nisDomainName. Could
>> this be changed with ldapmodify ?
> Sorry, I'm not sure. I hope someone with better insight into the IPA
> framework knows.

Morning Jakub, I sent a related post "default nisdomain appears to be
derived from hostname of first master rather than set to domain or
realm" and Alexander Bukovoy explained how to fix this.

Many Thanks

Bob Hinton

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Options for existing CA/DNS infrastructure

[David Kupka]

On Sun, Mar 12, 2017 at 10:47:02PM -0400, Rob Foehl wrote:
> I'm looking at deploying FreeIPA in a few environments with substantial DNS
> and/or CA infrastructure, and have some choices to make...
> 
> How much trouble will I have if FreeIPA is delegated a zone like
> ipa.example.com with all clients in example.com or other children?  (No
> overlap with AD-managed zones, but in at least one case autodiscovery won't
> be possible due to mixed clients in the parent zone.)
> 
> What's the best way to play nice with existing PKI -- generate a CA CSR at
> installation time and sign that?  Is there any provision for automatically
> renewing these certs, say if the external CA were to be subsumed by a
> dedicated Dogtag instance?
> 
> Advice and experience appreciated, before I paint myself into a corner
> somewhere...  Thanks!
> 
> -Rob
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

Hello Rob,
FreeIPA can be deployed in environment with existing DNS and/or CA server.
IIRC you have following options:
- regarding DNS:
-- Delegate DNS zone for FreeIPA. It will then manage the zone and add records
there. Obviously, it will not add records for clients in other zones.

-- Don't setup DNS in FreeIPA and keep managing all records in your current DNS
server. There's plan to integrate with external DNS servers [1] but nothing was
done yet.

- regarding CA:
-- install CA-less FreeIPA - you need to issue certificates for HTTPD and 389-DS
with your certificate server and provide those when installing FreeIPA server

-- install FreeIPA with CA certificate signed with external CA. Use
--external-ca option. The installation will be interupted to let you sign
generated CSR. FreeIPA will then issue all needed certificates.

-- install FreeIPA with self-signed CA certificate. This is default but then
you need to distribute the certificate to all clients.

Certmonger [2] is configured during ipa-server-install to track and renew
certificates.

[1] https://www.freeipa.org/page/V4/External_DNS_integration_with_installer
[2] https://pagure.io/certmonger

-- 
David Kupka


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] shadow netgroups with wrong domains - sudo problem

[Jakub Hrozek]

On Fri, Mar 17, 2017 at 01:52:17PM +, Bob Hinton wrote:
> On 17/03/2017 12:48, Lukas Slebodnik wrote:
> > On (17/03/17 10:40), Bob Hinton wrote:
> >> On 17/03/2017 08:41, Jakub Hrozek wrote:
> >>> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
>  Morning,
> 
>  We have a collection of hosts within prod1.local.lan. However, the
>  domain section of the shadow netgroups for the hosts is
>  mgmt.prod.local.lan. This seems to prevent sudo rules working on these
>  hosts unless they specify all hosts -
> 
>  -sh-4.2$ getent netgroup oepp_hosts
>  oepp_hosts   
>  (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>  (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>  (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>  (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>  (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>  -sh-4.2$ hostname
>  oeppredis001.z4.prod1.local.lan
>  -sh-4.2$ nisdomainname
>  local.lan
>  -sh-4.2$ domainname
>  local.lan
> 
>  The VMs associated with these hosts have recently been migrated and
>  re-enrolled against a new IPA server. The originals all had netgroup
>  domains of local.lan so something must have gone wrong in the migration
>  process. Is there a way to correct the netgroup domains of these hosts,
>  or is the only option to run ipa-client-install --uninstall followed by
>  ipa-client-install to reattach them ?
> >>> Did you remove the sssd cache after the migration?
> >>> rm -f /var/lib/sss/db/*.ldb
> >>>
> >>> (please make sure the clients can reach the server or maybe mv the cache
> >>> instead of rm so you can restore cached credentials if something goes
> >>> wrong..)
> >>>
> >> Hi Jakub,
> >>
> >> I've now tried removing the sssd cache on one of the offending servers
> >> and it's not made any difference.
> >>
> >> getent netgroup oepp_hosts
> >>
> >> when run from any host enrolled to the new IPA servers, including the
> >> IPA masters themselves produces the results with "mgmt.prod" included
> >> and the same thing run on any of the pre-migrated servers that are still
> >> commissioned produces them without, so I assume that the netgroup domain
> >> information is coming from the IPA masters rather than the local host.
> >>
> > Could you provide content of LDIF from IPA server?
> > For this netgroup/hostgroup
> >
> > LS
> 
> Hi Jakub,
> 
> I extracted the following from the userRoot ldif produced by "ipa-backup
> --data".
> 
> It appears to have the incorrect domain set against nisDomainName. Could
> this be changed with ldapmodify ?

Sorry, I'm not sure. I hope someone with better insight into the IPA
framework knows.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project