Re: [Freeipa-users] [SOLVED] Re: guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error

[Sumit Bose]

On Wed, Feb 01, 2017 at 02:41:35PM -0500, Chris Dagdigian wrote:
> 
> Update:
> 
> Resolved.  A bit of googling led me to some good RHEL pages as well as
> mailing list messages from Alex B that were concise and helpful.
> 
> To summarize for others who may have this problem:
> 
> 1. Don't make changes to sssd.conf if your provider is "ipa" - in this case
> you work only with "ipa idrange-mod" type commands or webUI
> 
> 2. The simple solution is to increase the range and restart SSSD after
> blowing away out of date sssd  database:
> 
> # ipa idrange-mod --base-id=400 --range-size=100
> EAME.COMPANY.ORG_id_range
> # service sssd stop; rm -f /var/lib/sss/db/*; service sssd start
> 
> 
> What I actually did on our IPA server was a bit more expansive. EAME was the
> first child domain where I had the SID to UID map issue but it would
> probably not have been the only one so I figured it would be safer to make
> sure that every child domain range had at least 1 million available IDs
> 
> Using the IPA webUI under "IPA Server" -> "ID Ranges" -> "Range Name"
> 
> I went through every single AD child domain and manually reconfigured both
> the "First Posix ID of the range" as well as "Number of IDs in the range" so
> we have at least 1,000,000 ID options in each child domain range:
> 
> APAC.COMPANY.ORG   1st-Posix=18   Ids-in-range: 100
> EAME.COMPANY.ORG   1st-Posix=181000   Ids-in-range: 100
> LATAM.COMPANY.ORG  1st-Posix=182000   Ids-in-range: 100
> NAFTA.COMPANY.ORG  1st-Posix=183000   Ids-in-range: 100
> 
> We are still in testing mode with less than 6 users logging in via IDM
> identities at the moment so it was not disruptive to make this sort of core
> change.

This is a valid way in testing mode. As I wrote in my other mail it is
possible and recommended in production to add additional idrange for a
domain to cover more RIDs if needed.

The difference is that the IPA server already checks if there are no
collisions in the idrange definitions and SSSD on the clients can then
just safely add the new idrange. If a definition of an idrange changes
it might be possible that existing ID-mappings changes, to be on the
safe side here SSSD requires a restart with removing the cache on all
clients.


HTH

bye,
Sumit

> 
> 
> -Chris
> 
> 
> 
> 
> 
> 
> 
> Chris Dagdigian wrote:
> > Hi folks,
> > 
> > I've posted here and gotten amazing help on our odd setup with IPA
> > having a 1-way trust to a massive remote AD forest with 90+ domain
> > controllers and lots of child domains.
> > 
> > I'm running into a strange issue where I can resolve and manage users in
> > child domain (NAFTA.COMPANY.ORG) but I am getting failures and just
> > discovered an interesting error that relates to resolving a user in the
> > EAME.COMPANY.ORG forrest.
> > 
> > However I've also been dragged down the rabbit hole tracking down errors
> > that turned out to be meaningless so I figured my 1st question will be
> > "is this the error should I be focusing on?"
> > 
> > This is my situation:
> > 
> > 1. "id u...@nafta.company.org" works perfectly fine - no issues at all
> > with RBAC, sudo and hosting SSH keys etc.
> > 
> > 2. "id u...@eame.company.org" fails with "no such user"
> > 
> > 3. We did not configure any specific SID-UID mapping rules in sssd.conf
> > as we had assumed we'd use the "default" behavior
> > 
> > 
> > After digging through the logs I found this which seems VERY clear about
> > the root cause:
> > 
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [dp_get_account_info_handler] (0x0200): Got request for
> > [0x1][BE_REQ_USER][1][name=u474...@eame.company.org]
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [sdap_idmap_sid_to_unix] (0x0040): Object SID
> > [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger
> > than the ldap_idmap_range_size. See the "ID MAPPING” section of
> > sssd-ad(5) for an explanation of how to resolve this issue.
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
> > [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user]
> > (0x0020): Failed to save user [u474...@eame.company.org]
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users]
> > (0x0040): Failed to store user 0. Ignoring.
> > 
> > 
> > The error about "Object SID has a RID that is larger than
> > ldap_idmap_range_size .." seems pretty clear. I don't think this is a
> > 'rabbit hole' message - this seems like a real config problem on my end.
> > 
> > The problem is that I'm not quite sure what I should configure to
> > resolve this. The man page for sssd-ad covers the topic but does not
> > cover recommended configuration options.
> > 
> > 
> > Questions for this list:
> > 
> > 1) Confirm that the "SID has an RID that is larger ..." error is real
> > and worth chasing down ?
> > 

Re: [Freeipa-users] guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error

[Sumit Bose]

On Wed, Feb 01, 2017 at 12:29:37PM -0500, Chris Dagdigian wrote:
> Hi folks,
> 
> I've posted here and gotten amazing help on our odd setup with IPA having a
> 1-way trust to a massive remote AD forest with 90+ domain controllers and
> lots of child domains.
> 
> I'm running into a strange issue where I can resolve and manage users in
> child domain (NAFTA.COMPANY.ORG) but I am getting failures and just
> discovered an interesting error that relates to resolving a user in the
> EAME.COMPANY.ORG forrest.
> 
> However I've also been dragged down the rabbit hole tracking down errors
> that turned out to be meaningless so I figured my 1st question will be "is
> this the error should I be focusing on?"
> 
> This is my situation:
> 
> 1. "id u...@nafta.company.org" works perfectly fine - no issues at all with
> RBAC, sudo and hosting SSH keys etc.
> 
> 2. "id u...@eame.company.org" fails with "no such user"
> 
> 3. We did not configure any specific SID-UID mapping rules in sssd.conf as
> we had assumed we'd use the "default" behavior
> 
> 
> After digging through the logs I found this which seems VERY clear about the
> root cause:
> 
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> [dp_get_account_info_handler] (0x0200): Got request for
> [0x1][BE_REQ_USER][1][name=u474...@eame.company.org]
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> [sdap_idmap_sid_to_unix] (0x0040): Object SID
> [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger
> than the ldap_idmap_range_size. See the "ID MAPPING” section of sssd-ad(5)
> for an explanation of how to resolve this issue.
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
> [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user]
> (0x0020): Failed to save user [u474...@eame.company.org]
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users]
> (0x0040): Failed to store user 0. Ignoring.
> 
> 
> The error about "Object SID has a RID that is larger than
> ldap_idmap_range_size .." seems pretty clear. I don't think this is a
> 'rabbit hole' message - this seems like a real config problem on my end.

Yes, unfortunately this messages is a bit misleading on an IPA client
because here you do not have to fix the local configuration but you only
have to add an id-range on an IPA server. Please check the existing
id-ranges with

ipa idrange-find

There should be already one for EAME.COMPANY.ORG with the default size
of 20 ("Number of IDs in the range: 20"). Please add a second
idrange for EAME.COMPANY.ORG which covers the RIDs above 20. If you
need help with choosing the parameters please send the idrange-find
output.

HTH

bye,
Sumit

> 
> The problem is that I'm not quite sure what I should configure to resolve
> this. The man page for sssd-ad covers the topic but does not cover
> recommended configuration options.
> 
> 
> Questions for this list:
> 
> 1) Confirm that the "SID has an RID that is larger ..." error is real and
> worth chasing down ?
> 
> 2) My understanding was that by default SSSD will hash SIDs and come up with
> unique UID and GID ranges that will be consistent across any machine bound
> to the same IDM mechanism. So I've not configured anything specific related
> to SID-to-UID mapping as we wanted to go with the default behavior used by
> SSSD. Obviously the default is not working and I've got to make a change. I
> just don't know what the recommended change should be. Help appreciated!
> 
> 
> 
> Config file details are below.
> 
> 
> Regards,
> Chris
> 
> 
> 
> 
> 
> This is the sssd/sssd.conf file on the IPA server:
> 
> ###--
> 
> [domain/companyidm.org]
> ldap_user_principal = nosuchattr
> subdomain_inherit = ldap_user_principal
> debug_level = 5
> krb5_validate = True
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = companyidm.org
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = usaeilidmp001.companyidm.org
> chpass_provider = ipa
> ipa_server = usaeilidmp001.companyidm.org
> ipa_server_mode = True
> ldap_tls_cacert = /etc/ipa/ca.crt
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> 
> domains = companyidm.org
> [nss]
> memcache_timeout = 600
> homedir_substring = /home
> 
> [pam]
> debug_level = 5
> [sudo]
> 
> [autofs]
> 
> [ssh]
> debug_level = 5
> 
> [pac]
> 
> [ifp]
> 
> ###--
> 
> 
> This is krb5.conf which handles the child domain and trust things ...
> 
> [capaths]
> COMPANYAWS.ORG = {
> COMPANYIDM.ORG = COMPANYAWS.ORG
> }
> COMPANYIDM.ORG = {
> COMPANYAWS.ORG = COMPANYAWS.ORG
> SYNGENTA.ORG = COMPANY.ORG
> EAME.COMPANY.ORG = SYNGENTA.ORG
> APAC.COMPANY.ORG = SYNGENTA.ORG
> LATAM.COMPANY.ORG = SYNGENTA.ORG
> NAFTA.COMPANY.ORG = SYNGENTA.ORG
> }
> COMPANY.ORG = {
> COMPANYIDM.ORG = COMPANY.ORG
> }
> 

Re: [Freeipa-users] Gateway_timeout Error

[deepak dimri]

Hey Martin,


Is gateway error has anything to do with --no-wait-for-dns flag that i used
when i created the replica image? i have another test IPA setup working
fine in the same env and the only difference i see that in that env i did
not use --no-wait-for-dns for replicas

Thanks,
Deepak

On Wed, Feb 1, 2017 at 10:52 PM, deepak dimri 
wrote:

> sorry for not replying to all!
>
> I have apache reverse proxy front ending the ipa servers. As i mentioned
> if i try hitting ipa replica WebUI directly then i do get the objects
> loaded on the browser after waiting for over a minute or so. replica server
> (/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}) shows hits coming
> through fine but for some reasons web browser ends up with the gateway
> error.
>
> both the ipa masters are running VERSION: 4.4.0, API_VERSION: 2.213
>
> Kind Regards,
> Deepak
>
>
> On Wed, Feb 1, 2017 at 9:21 PM, Martin Babinsky 
> wrote:
>
>> On 02/01/2017 04:26 PM, deepak dimri wrote:
>>
>>> Yes, Martin - i do see requests hitting
>>> replica.. /var/log/httpd/error_log shows:
>>>
>>> [Wed Feb 01 15:16:47.469766 2017] [:error] [pid 2464] ipa: INFO:
>>> ad...@xxx.xyz.com : batch:
>>> host_show(u'xxx.abx.xyz ', rights=True, all=True):
>>> SUCCESS
>>>
>>> I used ansible playbook to build the replica server. ran
>>> ipa-replica-prepare on the primary:
>>> ipa-replica-prepare {{ replica_dns }} --password={{ipa_password}}
>>> --no-wait-for-dns
>>>
>>> copied the replica file over to replica server:
>>> scp -oStrictHostKeyChecking=no -i ~/.ssh/{{ssh_keyname}}.pem
>>> /var/lib/ipa/replica-info-{{ replica_dns }}.gpg root@{{
>>> replica_dns }}:/var/lib/ipa/
>>>
>>> ran the replica install on the replica server:
>>> ipa-replica-install /var/lib/ipa/replica-info-{{  replica_dns }}.gpg
>>> --password={{ipa_password}} --admin-password={{ipa_password}}
>>>
>>> I have notices that if i directly use the replica (bypassing proxy)  URL
>>> then the objects shows after waiting for over a minute or so. When i use
>>> proxy pass then it just times out after few seconds.
>>>
>>> No clue why its behaving like this
>>>
>>> Many Thanks,
>>> Deepak
>>>
>>> On Wed, Feb 1, 2017 at 6:45 PM, Martin Babinsky >> > wrote:
>>>
>>> On 02/01/2017 11:17 AM, deepak dimri wrote:
>>>
>>> Hello Martin, Thank you so much for your reply.
>>>
>>> I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary
>>> server and
>>> its pointing to its own hostname and not to primary server
>>> hostname :(
>>>
>>> any other clue, Martin?
>>>
>>> I have tried without proxy and again to luck either its throwing
>>> same
>>> gateway_error
>>>
>>> Regards,
>>> Deepak
>>>
>>> On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky
>>> 
>>> >>
>>> wrote:
>>>
>>> On 02/01/2017 10:22 AM, deepak dimri wrote:
>>>
>>> Hi All,
>>>
>>> I have two IPA servers - primary and secondary running.
>>> the
>>> secondary
>>> ipa server is installed using ipa replica image of
>>> primary.
>>> While doing
>>> the testing i realised that when i manually shut down my
>>> primary ipa
>>> server making my secondary server to serve the UI. And
>>> now when
>>> i try to
>>> access user or hosts details using my secondary server
>>> then i am
>>> getting
>>> below error in the UI. I am able to login fine though;
>>> it is
>>> just that
>>> when i double click on host objects then i get the error.
>>>
>>>
>>>   An error has occurred (GATEWAY_TIMEOUT)
>>>
>>>
>>> I am still trying to troubleshoot as why i am getting
>>> timeout
>>> error but
>>> thought of asking the group here to see if some one can
>>> share
>>> some pointers
>>>
>>> Many Thanks,
>>> Deepak
>>>
>>>
>>> Hi Deepak,
>>>
>>> please check /etc/ipa/default.conf on the secondary server
>>> and check
>>> the value of 'xmlrpc_uri'. Maybe it points to the URL of
>>> primary
>>> server and that's why you get timeouts when it is down.
>>>
>>> Re-setting it to the secondary server itself should fix it.
>>>
>>> --
>>> Martin^3 Babinsky
>>>
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> 

Re: [Freeipa-users] Dogtag vs Freeipa Dogtag

[Fraser Tweedale]

On Wed, Feb 01, 2017 at 09:44:34PM +0100, Gorazd wrote:
> Hello,
> 
> i am interested if there is any feature matrix available for FreeIpa
> version of dogtag packaging. So which features of DogTak are not included
> or does come with limitations when installed with Freeipa (such as OCSP is
> already part of CA and could not be installed seperately), in contrast when
> on uses Dogtag as a standlone software installation?
> 
FreeIPA does not use the standalone OCSP responder, or the token
processing subsystems (TKS/TPS).  There is nothing preventing you
from installing them, but FreeIPA won't help you to do that, and
there is no integration.

Cheers,
Fraser

> Thank you in advance.
> 
> Regards,
> Gorazd

> -- 
> 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] Is WinSync A Bad Choice?

[Lachlan Musicman]

On 2 February 2017 at 10:06, Jason B. Nance  wrote:

>
> >- User/group management in general becomes largely a command-line
>> operation (such as mapping groups so they can be used in HBAC and sudo
>> rules)
>>
>> While this is a nice-to-have, it isn't a deal breaker.
>>
>
> This definitely exists in WebUI? Unless you mean something I don't
> understand.
>
> Define groups:
> Identity->User Groups (second tab)
>
> In my setup (FreeIPA 4.4.0 on CentOS 7) I don't see external users (users
> that are known via the trust with AD) under the "Users" tab.  There is
> limited visibility / management of external groups and membership, but
> nothing that displays a list of available users/groups in AD when
> attempting to create/modify a user/group.
>



Ah! Yes, I can't see all the AD users either. But adding a user to the ID
Views does fail on bad user names, which is not the same thing - I know -
but I only have a one way trust (from FreeIPA to AD) and the AD is managed
by the IT Overlords on Floor 6.

Bi directional trust may have different usage?


> Define user mappings:
> IPA Server -> ID Views -> Default Trust View
>
> By "mapping" I meant adding an AD group to a FreeIPA group (which can be
> used for HBAC/sudo) so that AD membership is known by IPA when applying the
> HBAC/sudo rules.  For example:
>
> ipa group-add \
>   --desc="lab.gen.zone 'Domain Admins' external map" \
>   lgz_map_domain_admins \
>   --external
> ipa group-add \
>   --desc="lab.gen.zone 'Domain Admins' POSIX" \
>   lgz_domain_admins
> ipa group-add-member \
>   lgz_map_domain_admins \
>   --external 'LAB\Domain Admins'
> ipa group-add-member \
>   lgz_domain_admins \
>   --groups lgz_map_domain_admins
>
>


Through the groups UI, you can add an external group (we use the naming
system "ad_my_group"), then add the AD group as an external member to that
group (add AD-DOMAIN\my_group). Then we add the local POSIX group
("my_group")  and make "ad_my_group" a member of that.


When you add a group in the groups, you will see the option for the group
to be POSIX, external or normal.

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] Is WinSync A Bad Choice?

[Martin Basti]

On 02.02.2017 00:05, Lachlan Musicman wrote:
On 2 February 2017 at 09:51, Martin Basti > wrote:



On 01.02.2017 23:44, Lachlan Musicman wrote:



(aside: does FreeIPA have plans to move toward PatternFly?
http://www.patternfly.org/ )


Unless I missed something, FreeIPA 4.x already uses patternfly

https://ipa.demo1.freeipa.org/ipa/ui/

admin/Secret123


Ah! The thing I am missing is IPA 4.4! (still on 4.2. Upgrade in the 
planning)


cheers
L.


Actually patternfly is there since 4.0.0

http://www.freeipa.org/page/Releases/4.0.0

"""
Web UI adopted Patternfly open interface project to promote design 
commonality and improved user experience. Web UI is now responsive and 
adapts to different screen sizes like mobile or tablets.

"""

So you should see it on 4.2, if not you have something broken :)
-- 
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] Is WinSync A Bad Choice?

[Jason B. Nance]

>>> - User/group management in general becomes largely a command-line operation
>> > (such as mapping groups so they can be used in HBAC and sudo rules)

>> While this is a nice-to-have, it isn't a deal breaker.

> This definitely exists in WebUI? Unless you mean something I don't understand.

> Define groups:
> Identity->User Groups (second tab)

In my setup (FreeIPA 4.4.0 on CentOS 7) I don't see external users (users that 
are known via the trust with AD) under the "Users" tab. There is limited 
visibility / management of external groups and membership, but nothing that 
displays a list of available users/groups in AD when attempting to 
create/modify a user/group. 
> Define user mappings:
> IPA Server -> ID Views -> Default Trust View

By "mapping" I meant adding an AD group to a FreeIPA group (which can be used 
for HBAC/sudo) so that AD membership is known by IPA when applying the 
HBAC/sudo rules. For example: 

ipa group-add \ 
--desc="lab.gen.zone 'Domain Admins' external map" \ 
lgz_map_domain_admins \ 
--external 
ipa group-add \ 
--desc="lab.gen.zone 'Domain Admins' POSIX" \ 
lgz_domain_admins 
ipa group-add-member \ 
lgz_map_domain_admins \ 
--external 'LAB\Domain Admins' 
ipa group-add-member \ 
lgz_domain_admins \ 
--groups lgz_map_domain_admins 
-- 
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] Is WinSync A Bad Choice?

[Lachlan Musicman]

On 2 February 2017 at 09:51, Martin Basti  wrote:

>
> On 01.02.2017 23:44, Lachlan Musicman wrote:
>
>
>
> (aside: does FreeIPA have plans to move toward PatternFly?
> http://www.patternfly.org/ )
>
>
> Unless I missed something, FreeIPA 4.x already uses patternfly
>
> https://ipa.demo1.freeipa.org/ipa/ui/
> admin/Secret123
>
>
Ah! The thing I am missing is IPA 4.4! (still on 4.2. Upgrade in the
planning)

cheers
L.
-- 
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] Is WinSync A Bad Choice?

[Martin Basti]

On 01.02.2017 23:44, Lachlan Musicman wrote:
On 2 February 2017 at 09:19, Jason B. Nance > wrote:


>- User/group management in general becomes largely a command-line
operation (such as mapping groups so they can be used in HBAC and
sudo rules)

While this is a nice-to-have, it isn't a deal breaker.


This definitely exists in WebUI? Unless you mean something I don't 
understand.


Define groups:
Identity->User Groups (second tab)

Define user mappings:
IPA Server -> ID Views -> Default Trust View

Is that what you mean?

(aside: does FreeIPA have plans to move toward PatternFly? 
http://www.patternfly.org/ )


Unless I missed something, FreeIPA 4.x already uses patternfly

https://ipa.demo1.freeipa.org/ipa/ui/
admin/Secret123

Martin





cheers
L.






-- 
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] Is WinSync A Bad Choice?

[Lachlan Musicman]

On 2 February 2017 at 09:19, Jason B. Nance  wrote:

> >- User/group management in general becomes largely a command-line
> operation (such as mapping groups so they can be used in HBAC and sudo
> rules)
>
> While this is a nice-to-have, it isn't a deal breaker.
>

This definitely exists in WebUI? Unless you mean something I don't
understand.

Define groups:
Identity->User Groups (second tab)

Define user mappings:
IPA Server -> ID Views -> Default Trust View

Is that what you mean?

(aside: does FreeIPA have plans to move toward PatternFly?
http://www.patternfly.org/ )

cheers
L.
-- 
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] Is WinSync A Bad Choice?

[Jason B. Nance]

>> - Users can't login to a Linux box using just "username" (user@ad.domain 
>> is
>> used)
> 
> In the current version you can use the 'default_domain_suffix' option in
> sssd.conf on the clients. In RHEL-7.4 we are looking into making this
> limitation go away.

Thank you very much, Jakub.  That is helpful information!  Are you saying that 
there will basically be a domain search order or something for users that login 
without specifying a domain?

Back to the community as a whole, regarding these other items:

>- Since AD trust users don't show up in FreeIPA web UI users can't login 
> to manage their own SSH keys

After doing some additional thinking/researching I realized that SSH keys 
become largely irrelevant because of GSSAPI (Dmitri Pal posed this question in 
this thread: 
https://www.redhat.com/archives/freeipa-users/2013-September/msg00290.html).

>- User/group management in general becomes largely a command-line 
> operation (such as mapping groups so they can be used in HBAC and sudo rules)

While this is a nice-to-have, it isn't a deal breaker.

I have another question.  Can additional authentication requirements (such as 
2FA) be imposed on users from a trust via IPA?

Thanks,

j

-- 
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] Is WinSync A Bad Choice?

[Jakub Hrozek]

On Wed, Feb 01, 2017 at 03:00:55PM -0600, Jason B. Nance wrote:
> Hello everyone,
> 
> I'm about to deploy a fresh IPA domain that needs to integrate with Active 
> Directory.  In my lab environment I've setup a trust with AD and the 
> following items are driving me away from using the trust:
> 
> - Users can't login to a Linux box using just "username" (user@ad.domain 
> is used)

In the current version you can use the 'default_domain_suffix' option in
sssd.conf on the clients. In RHEL-7.4 we are looking into making this
limitation go away.

(I won't reply to the other two questions because they are outside my
knowledge domain, sorry)

-- 
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] Is WinSync A Bad Choice?

[Jason B. Nance]

Hello everyone,

I'm about to deploy a fresh IPA domain that needs to integrate with Active 
Directory.  In my lab environment I've setup a trust with AD and the following 
items are driving me away from using the trust:

- Users can't login to a Linux box using just "username" (user@ad.domain is 
used)
- Since AD trust users don't show up in FreeIPA web UI users can't login to 
manage their own SSH keys
- User/group management in general becomes largely a command-line operation 
(such as mapping groups so they can be used in HBAC and sudo rules)

First, if any of the above is incorrect or there are workarounds I am very much 
open to discussion.

I'm considering using WinSync+PassSync so that users and groups appear as 
"real" IPA objects to be managed normally.  Given that an entire tool has been 
written to migrate away from WinSync to AD trusts and language in the RH 
documentation suggesting to only use WinSync if you have to I'm wondering what 
issues I'm not considering and if I could be leading toward a world of hurt.

Guidance in this area is appreciated.

Thanks,

j

-- 
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] Dogtag vs Freeipa Dogtag

[Gorazd]

Hello,

i am interested if there is any feature matrix available for FreeIpa
version of dogtag packaging. So which features of DogTak are not included
or does come with limitations when installed with Freeipa (such as OCSP is
already part of CA and could not be installed seperately), in contrast when
on uses Dogtag as a standlone software installation?

Thank you in advance.

Regards,
Gorazd
-- 
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] Replica FQDN / Domain question

[Christophe TREFOIS]

Hi Martin,

Thanks for the reply! That's the plan. As we can't really change REALM easily 
or as it's not recommended, we have to unfortunately drag this "issue" with us.

This by the way, leads us to not being able to setup SRV records as we collide 
with an AD in the same organisation. Real shame realm can't be changed somehow. 
For now, no failover for us.

Kind regards,
Christophe

Sent from my iPhone

On 1 Feb 2017, at 14:18, Martin Basti 
> wrote:



On 01.02.2017 14:06, Christophe TREFOIS wrote:
Hi all,

Small question which might be naive.

We have an existing setup with 4 replicas, all with FQDNs like 
replica1.example.com and REALM 
example.com.

We want to add another replica, replica5, whose FQDN would have a different 
domain, so say replica5.example.org.
The DNS would be resolvable as it would be managed by the same DNS server 
(outside of our control).

We don’t think this should have any impact.

Is this a fair assumption? We just want to make sure.

Kind regards,
Christophe


It should work, but keep on mind that replica5 will be still part of realm 
EXAMPLE.COM

Martin
-- 
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] unable to delete a user - which has a double??

[Jochen Hein]

Hi

lejeczek  writes:

> I think it had something to do with an initial(long time ago)
> migration.
> How to safely delete such a user? Or one of them?
>
> $ ipa user-del appmgr --no-preserve
> ipa: ERROR: The search criteria was not specific enough. Expected 1
> and found 2.

Did you try "--continue"?

You can check both users with "ipa user-find ... --all" and look for the
ipauniqueid. I think you'll can remove the user with ldapremove. 

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] [SOLVED] Re: guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error

[Chris Dagdigian]

Update:

Resolved.  A bit of googling led me to some good RHEL pages as well as 
mailing list messages from Alex B that were concise and helpful.


To summarize for others who may have this problem:

1. Don't make changes to sssd.conf if your provider is "ipa" - in this 
case you work only with "ipa idrange-mod" type commands or webUI


2. The simple solution is to increase the range and restart SSSD after 
blowing away out of date sssd  database:


# ipa idrange-mod --base-id=400 --range-size=100 
EAME.COMPANY.ORG_id_range

# service sssd stop; rm -f /var/lib/sss/db/*; service sssd start


What I actually did on our IPA server was a bit more expansive. EAME was 
the first child domain where I had the SID to UID map issue but it would 
probably not have been the only one so I figured it would be safer to 
make sure that every child domain range had at least 1 million available 
IDs


Using the IPA webUI under "IPA Server" -> "ID Ranges" -> "Range Name"

I went through every single AD child domain and manually reconfigured 
both the "First Posix ID of the range" as well as "Number of IDs in the 
range" so we have at least 1,000,000 ID options in each child domain range:


APAC.COMPANY.ORG   1st-Posix=18   Ids-in-range: 100
EAME.COMPANY.ORG   1st-Posix=181000   Ids-in-range: 100
LATAM.COMPANY.ORG  1st-Posix=182000   Ids-in-range: 100
NAFTA.COMPANY.ORG  1st-Posix=183000   Ids-in-range: 100

We are still in testing mode with less than 6 users logging in via IDM 
identities at the moment so it was not disruptive to make this sort of 
core change.



-Chris







Chris Dagdigian wrote:

Hi folks,

I've posted here and gotten amazing help on our odd setup with IPA 
having a 1-way trust to a massive remote AD forest with 90+ domain 
controllers and lots of child domains.


I'm running into a strange issue where I can resolve and manage users 
in child domain (NAFTA.COMPANY.ORG) but I am getting failures and just 
discovered an interesting error that relates to resolving a user in 
the EAME.COMPANY.ORG forrest.


However I've also been dragged down the rabbit hole tracking down 
errors that turned out to be meaningless so I figured my 1st question 
will be "is this the error should I be focusing on?"


This is my situation:

1. "id u...@nafta.company.org" works perfectly fine - no issues at all 
with RBAC, sudo and hosting SSH keys etc.


2. "id u...@eame.company.org" fails with "no such user"

3. We did not configure any specific SID-UID mapping rules in 
sssd.conf as we had assumed we'd use the "default" behavior



After digging through the logs I found this which seems VERY clear 
about the root cause:


(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] 
[dp_get_account_info_handler] (0x0200): Got request for 
[0x1][BE_REQ_USER][1][name=u474...@eame.company.org]
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] 
[sdap_idmap_sid_to_unix] (0x0040): Object SID 
[S-1-5-21-299502267-823518204-725345543-201173] has a RID that is 
larger than the ldap_idmap_range_size. See the "ID MAPPING” section of 
sssd-ad(5) for an explanation of how to resolve this issue.
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] 
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID 
[S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user] 
(0x0020): Failed to save user [u474...@eame.company.org]
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users] 
(0x0040): Failed to store user 0. Ignoring.



The error about "Object SID has a RID that is larger than 
ldap_idmap_range_size .." seems pretty clear. I don't think this is a 
'rabbit hole' message - this seems like a real config problem on my end.


The problem is that I'm not quite sure what I should configure to 
resolve this. The man page for sssd-ad covers the topic but does not 
cover recommended configuration options.



Questions for this list:

1) Confirm that the "SID has an RID that is larger ..." error is real 
and worth chasing down ?


2) My understanding was that by default SSSD will hash SIDs and come 
up with unique UID and GID ranges that will be consistent across any 
machine bound to the same IDM mechanism. So I've not configured 
anything specific related to SID-to-UID mapping as we wanted to go 
with the default behavior used by SSSD. Obviously the default is not 
working and I've got to make a change. I just don't know what the 
recommended change should be. Help appreciated!




Config file details are below.


Regards,
Chris





This is the sssd/sssd.conf file on the IPA server:

###--

[domain/companyidm.org]
ldap_user_principal = nosuchattr
subdomain_inherit = ldap_user_principal
debug_level = 5
krb5_validate = True
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = companyidm.org
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = 

Re: [Freeipa-users] unable to delete a user - which has a double??

[Martin Basti]

Hello,

you have to use ldapdelete command and remove it manually

Martin


On 01.02.2017 19:30, lejeczek wrote:

hi all,
take a look:

$ ipa user-find --uid 3501
--
1 user matched
--
  User login: appmgr
  First name: app
  Last name: developer
  Home directory: /home.sysops/appmgr
  Login shell: /bin/bash
  Principal alias: appmgr@PRIVATE
  Email address: appmgr@private
  UID: 3501
  GID: 3501
  Account disabled: False

$ ipa user-find --uid 1104
--
1 user matched
--
  User login: appmgr
  First name: app
  Last name: devel 1
  Home directory: /home.sysops/appmgr
  Login shell: /bin/bash
  Principal alias: appmgr@PRIVATE
  Email address: appmgr@private
  UID: 1104
  GID: 1104
  Account disabled: False

Number of entries returned 1


I think it had something to do with an initial(long time ago) migration.
How to safely delete such a user? Or one of them?

$ ipa user-del appmgr --no-preserve
ipa: ERROR: The search criteria was not specific enough. Expected 1 
and found 2.


many thanks,
L.



--
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] unable to delete a user - which has a double??

[lejeczek]

hi all,
take a look:

$ ipa user-find --uid 3501
--
1 user matched
--
  User login: appmgr
  First name: app
  Last name: developer
  Home directory: /home.sysops/appmgr
  Login shell: /bin/bash
  Principal alias: appmgr@PRIVATE
  Email address: appmgr@private
  UID: 3501
  GID: 3501
  Account disabled: False

$ ipa user-find --uid 1104
--
1 user matched
--
  User login: appmgr
  First name: app
  Last name: devel 1
  Home directory: /home.sysops/appmgr
  Login shell: /bin/bash
  Principal alias: appmgr@PRIVATE
  Email address: appmgr@private
  UID: 1104
  GID: 1104
  Account disabled: False

Number of entries returned 1


I think it had something to do with an initial(long time 
ago) migration.

How to safely delete such a user? Or one of them?

$ ipa user-del appmgr --no-preserve
ipa: ERROR: The search criteria was not specific enough. 
Expected 1 and found 2.


many thanks,
L.

--
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] Gateway_timeout Error

[deepak dimri]

sorry for not replying to all!

I have apache reverse proxy front ending the ipa servers. As i mentioned if
i try hitting ipa replica WebUI directly then i do get the objects loaded
on the browser after waiting for over a minute or so. replica server
(/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}) shows hits coming
through fine but for some reasons web browser ends up with the gateway
error.

both the ipa masters are running VERSION: 4.4.0, API_VERSION: 2.213

Kind Regards,
Deepak


On Wed, Feb 1, 2017 at 9:21 PM, Martin Babinsky  wrote:

> On 02/01/2017 04:26 PM, deepak dimri wrote:
>
>> Yes, Martin - i do see requests hitting
>> replica.. /var/log/httpd/error_log shows:
>>
>> [Wed Feb 01 15:16:47.469766 2017] [:error] [pid 2464] ipa: INFO:
>> ad...@xxx.xyz.com : batch:
>> host_show(u'xxx.abx.xyz ', rights=True, all=True):
>> SUCCESS
>>
>> I used ansible playbook to build the replica server. ran
>> ipa-replica-prepare on the primary:
>> ipa-replica-prepare {{ replica_dns }} --password={{ipa_password}}
>> --no-wait-for-dns
>>
>> copied the replica file over to replica server:
>> scp -oStrictHostKeyChecking=no -i ~/.ssh/{{ssh_keyname}}.pem
>> /var/lib/ipa/replica-info-{{ replica_dns }}.gpg root@{{
>> replica_dns }}:/var/lib/ipa/
>>
>> ran the replica install on the replica server:
>> ipa-replica-install /var/lib/ipa/replica-info-{{  replica_dns }}.gpg
>> --password={{ipa_password}} --admin-password={{ipa_password}}
>>
>> I have notices that if i directly use the replica (bypassing proxy)  URL
>> then the objects shows after waiting for over a minute or so. When i use
>> proxy pass then it just times out after few seconds.
>>
>> No clue why its behaving like this
>>
>> Many Thanks,
>> Deepak
>>
>> On Wed, Feb 1, 2017 at 6:45 PM, Martin Babinsky > > wrote:
>>
>> On 02/01/2017 11:17 AM, deepak dimri wrote:
>>
>> Hello Martin, Thank you so much for your reply.
>>
>> I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary
>> server and
>> its pointing to its own hostname and not to primary server
>> hostname :(
>>
>> any other clue, Martin?
>>
>> I have tried without proxy and again to luck either its throwing
>> same
>> gateway_error
>>
>> Regards,
>> Deepak
>>
>> On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky
>> 
>> >> wrote:
>>
>> On 02/01/2017 10:22 AM, deepak dimri wrote:
>>
>> Hi All,
>>
>> I have two IPA servers - primary and secondary running.
>> the
>> secondary
>> ipa server is installed using ipa replica image of
>> primary.
>> While doing
>> the testing i realised that when i manually shut down my
>> primary ipa
>> server making my secondary server to serve the UI. And
>> now when
>> i try to
>> access user or hosts details using my secondary server
>> then i am
>> getting
>> below error in the UI. I am able to login fine though; it
>> is
>> just that
>> when i double click on host objects then i get the error.
>>
>>
>>   An error has occurred (GATEWAY_TIMEOUT)
>>
>>
>> I am still trying to troubleshoot as why i am getting
>> timeout
>> error but
>> thought of asking the group here to see if some one can
>> share
>> some pointers
>>
>> Many Thanks,
>> Deepak
>>
>>
>> Hi Deepak,
>>
>> please check /etc/ipa/default.conf on the secondary server
>> and check
>> the value of 'xmlrpc_uri'. Maybe it points to the URL of
>> primary
>> server and that's why you get timeouts when it is down.
>>
>> Re-setting it to the secondary server itself should fix it.
>>
>> --
>> Martin^3 Babinsky
>>
>> --
>> 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
>>
>>
>>
>> Adding freeipa-users back to loop.
>>
>> That is strange, how did you stand up the replica?
>>
>> You can also inspect /var/log/http/error_log on the replica to see
>> whether the commands from the WebUI reach the local HTTP server at
>> all.
>>
>> --
>> Martin^3 

Re: [Freeipa-users] Backend & UI plugin update for 4.4.x

[Steve Huston]

Awesome!  Thank you.

On Wed, Feb 1, 2017 at 12:05 PM, Florence Blanc-Renaud  wrote:
> On 02/01/2017 05:47 PM, Steve Huston wrote:
>>
>> Would it be better to file this as a new bug, or reopen 4291?
>>
> Hi,
>
> we are already aware of the problem and working on a fix (please see
> https://bugzilla.redhat.com/show_bug.cgi?id=1398600 and
> https://fedorahosted.org/freeipa/ticket/6575).
>
> HTH,
> Flo.
>
>
>> On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston
>>  wrote:
>>>
>>> Seems like this is to blame:
>>> https://fedorahosted.org/freeipa/ticket/4291
>>>
>>> The checkin says, "Installation in pure IPv6 environment failed
>>> because pki-tomcat tried to use
>>> IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4
>>> fixes this issue."  However it would seem that in a pure IPv4
>>> environment, this is causing tomcat to fail to load.
>>>
>>> On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston
>>>  wrote:

 What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml?

 

 >>> address="::1" />

 Doesn't work so well on a host without IPv6 turned on...

 Jan 31 14:26:59 ipa server: PKIListener:
 org.apache.catalina.core.StandardServer[before_init]
 Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point
 associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"]
 Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family
 unavailable

 On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston
  wrote:
>
> Stranger, I did an install on a different VM with the CentOS 7 minimal
> ISO, then installed ipa-server and enough things to get X11 and
> Firefox, ran ipa-server-install and it worked fine.  I tested with
> Firefox (and Safari) against my failing installation and it still
> fails.  So there's something else different that's causing it to
> break.  Will continue investigating, but if someone knows why the UI
> would break this way it would be helpful to know where to look!
>
> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston
>  wrote:
>>
>> Just did it again with the same result.  Reinstalled the machine, then
>> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in
>> version 4.4.0-14.el7_3.4 and a bunch of other packages.  Next was the
>> ipa-server-install as I used before, only without --mkhomedir this
>> time.  After entering the passwords for directory administrator and
>> the admin user, I then logged in to the web interface, immediately
>> clicked "add" and added a user 'foobar'.  When I clicked "add and
>> edit" and was brought to the user information page, it looks like this
>> at the bottom:
>>
>>
>> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0
>>
>> I then entered an employee number of '0001' just to give something to
>> save, and clicked save.  The screen now shows this (I've clicked the
>> drop-down on the manager field so the choices are visible):
>>
>>
>> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0
>>
>> Holding shift and clicking reload, the page now looks like this (the
>> employee number field is also blank again):
>>
>>
>> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0
>>
>> Since we do run a repackaged distribution here (Springdale Linux), I
>> just unpacked ipa-server-common from our repository with the above
>> version, and
>> http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm,
>> and 'diff' found zero differences between them.  Unlikely, but I
>> wanted to rule out a packaging error causing the problem.
>>
>> On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston
>>  wrote:
>>>
>>> No, that should be all of the major changes; the puppet module that
>>> installs things only puts the two plugin files in their respective
>>> places.  The client part of the IPA module makes changes to have the
>>> machine join the domain and whatnot, but those shouldn't affect the
>>> webui.
>>>
>>> I do modify the schema by adding some attribute types for Puppet,
>>> namely puppetClass, parentNode, environment, puppetVar, and the
>>> object
>>> class puppetClient.  That's basically right from one of the Puppet
>>> webpages and also worked in the past - and is one of the things the
>>> python plugin does, add the appropriate objectclass to host entries
>>> if
>>> puppetVar is added to a host entry.
>>>
>>> My steps to install:
>>> * ipa-server-install --realm= --domain= --mkhomedir
>>> --hostname= 

Re: [Freeipa-users] Backend & UI plugin update for 4.4.x

[Florence Blanc-Renaud]

On 02/01/2017 05:47 PM, Steve Huston wrote:

Would it be better to file this as a new bug, or reopen 4291?


Hi,

we are already aware of the problem and working on a fix (please see 
https://bugzilla.redhat.com/show_bug.cgi?id=1398600 and 
https://fedorahosted.org/freeipa/ticket/6575).


HTH,
Flo.


On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston
 wrote:

Seems like this is to blame:  https://fedorahosted.org/freeipa/ticket/4291

The checkin says, "Installation in pure IPv6 environment failed
because pki-tomcat tried to use
IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4
fixes this issue."  However it would seem that in a pure IPv4
environment, this is causing tomcat to fail to load.

On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston
 wrote:

What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml?





Doesn't work so well on a host without IPv6 turned on...

Jan 31 14:26:59 ipa server: PKIListener:
org.apache.catalina.core.StandardServer[before_init]
Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point
associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"]
Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family
unavailable

On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston
 wrote:

Stranger, I did an install on a different VM with the CentOS 7 minimal
ISO, then installed ipa-server and enough things to get X11 and
Firefox, ran ipa-server-install and it worked fine.  I tested with
Firefox (and Safari) against my failing installation and it still
fails.  So there's something else different that's causing it to
break.  Will continue investigating, but if someone knows why the UI
would break this way it would be helpful to know where to look!

On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston
 wrote:

Just did it again with the same result.  Reinstalled the machine, then
did a 'yum install ipa-server python2-ipaserver httpd' which pulled in
version 4.4.0-14.el7_3.4 and a bunch of other packages.  Next was the
ipa-server-install as I used before, only without --mkhomedir this
time.  After entering the passwords for directory administrator and
the admin user, I then logged in to the web interface, immediately
clicked "add" and added a user 'foobar'.  When I clicked "add and
edit" and was brought to the user information page, it looks like this
at the bottom:

https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0

I then entered an employee number of '0001' just to give something to
save, and clicked save.  The screen now shows this (I've clicked the
drop-down on the manager field so the choices are visible):

https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0

Holding shift and clicking reload, the page now looks like this (the
employee number field is also blank again):

https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0

Since we do run a repackaged distribution here (Springdale Linux), I
just unpacked ipa-server-common from our repository with the above
version, and 
http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm,
and 'diff' found zero differences between them.  Unlikely, but I
wanted to rule out a packaging error causing the problem.

On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston
 wrote:

No, that should be all of the major changes; the puppet module that
installs things only puts the two plugin files in their respective
places.  The client part of the IPA module makes changes to have the
machine join the domain and whatnot, but those shouldn't affect the
webui.

I do modify the schema by adding some attribute types for Puppet,
namely puppetClass, parentNode, environment, puppetVar, and the object
class puppetClient.  That's basically right from one of the Puppet
webpages and also worked in the past - and is one of the things the
python plugin does, add the appropriate objectclass to host entries if
puppetVar is added to a host entry.

My steps to install:
* ipa-server-install --realm= --domain= --mkhomedir
--hostname= --no-host-dns
* ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W
  < paste puppet schema changes>
  < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a
service account used by puppet for adding hosts to IPA >
* login to web UI
* * Change home directory base, default shell, default SELinux user
* * Add SELinux user map for staff/sysadmin users
* * Add "user adder" permission/privilege/role for users who will be
able to create stageusers

That's about as far as I got before I realized some of the plugin
pieces weren't working, and then fixed the python plugin followed by
working on the UI plugin and finding this problem.  I'll go wipe and
reinstall the system again and walk through the steps, but test 

Re: [Freeipa-users] Backend & UI plugin update for 4.4.x

[Steve Huston]

Would it be better to file this as a new bug, or reopen 4291?

On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston
 wrote:
> Seems like this is to blame:  https://fedorahosted.org/freeipa/ticket/4291
>
> The checkin says, "Installation in pure IPv6 environment failed
> because pki-tomcat tried to use
> IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4
> fixes this issue."  However it would seem that in a pure IPv4
> environment, this is causing tomcat to fail to load.
>
> On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston
>  wrote:
>> What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml?
>>
>> 
>>
>> > address="::1" />
>>
>> Doesn't work so well on a host without IPv6 turned on...
>>
>> Jan 31 14:26:59 ipa server: PKIListener:
>> org.apache.catalina.core.StandardServer[before_init]
>> Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point
>> associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"]
>> Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family
>> unavailable
>>
>> On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston
>>  wrote:
>>> Stranger, I did an install on a different VM with the CentOS 7 minimal
>>> ISO, then installed ipa-server and enough things to get X11 and
>>> Firefox, ran ipa-server-install and it worked fine.  I tested with
>>> Firefox (and Safari) against my failing installation and it still
>>> fails.  So there's something else different that's causing it to
>>> break.  Will continue investigating, but if someone knows why the UI
>>> would break this way it would be helpful to know where to look!
>>>
>>> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston
>>>  wrote:
 Just did it again with the same result.  Reinstalled the machine, then
 did a 'yum install ipa-server python2-ipaserver httpd' which pulled in
 version 4.4.0-14.el7_3.4 and a bunch of other packages.  Next was the
 ipa-server-install as I used before, only without --mkhomedir this
 time.  After entering the passwords for directory administrator and
 the admin user, I then logged in to the web interface, immediately
 clicked "add" and added a user 'foobar'.  When I clicked "add and
 edit" and was brought to the user information page, it looks like this
 at the bottom:

 https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0

 I then entered an employee number of '0001' just to give something to
 save, and clicked save.  The screen now shows this (I've clicked the
 drop-down on the manager field so the choices are visible):

 https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0

 Holding shift and clicking reload, the page now looks like this (the
 employee number field is also blank again):

 https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0

 Since we do run a repackaged distribution here (Springdale Linux), I
 just unpacked ipa-server-common from our repository with the above
 version, and 
 http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm,
 and 'diff' found zero differences between them.  Unlikely, but I
 wanted to rule out a packaging error causing the problem.

 On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston
  wrote:
> No, that should be all of the major changes; the puppet module that
> installs things only puts the two plugin files in their respective
> places.  The client part of the IPA module makes changes to have the
> machine join the domain and whatnot, but those shouldn't affect the
> webui.
>
> I do modify the schema by adding some attribute types for Puppet,
> namely puppetClass, parentNode, environment, puppetVar, and the object
> class puppetClient.  That's basically right from one of the Puppet
> webpages and also worked in the past - and is one of the things the
> python plugin does, add the appropriate objectclass to host entries if
> puppetVar is added to a host entry.
>
> My steps to install:
> * ipa-server-install --realm= --domain= --mkhomedir
> --hostname= --no-host-dns
> * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W
>   < paste puppet schema changes>
>   < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a
> service account used by puppet for adding hosts to IPA >
> * login to web UI
> * * Change home directory base, default shell, default SELinux user
> * * Add SELinux user map for staff/sysadmin users
> * * Add "user adder" permission/privilege/role for users who will be
> able to create stageusers
>
> That's about as far as I got before I realized some of the plugin
> pieces 

Re: [Freeipa-users] Gateway_timeout Error

[Martin Babinsky]

On 02/01/2017 04:26 PM, deepak dimri wrote:

Yes, Martin - i do see requests hitting
replica.. /var/log/httpd/error_log shows:

[Wed Feb 01 15:16:47.469766 2017] [:error] [pid 2464] ipa: INFO:
ad...@xxx.xyz.com : batch:
host_show(u'xxx.abx.xyz ', rights=True, all=True):
SUCCESS

I used ansible playbook to build the replica server. ran
ipa-replica-prepare on the primary:
ipa-replica-prepare {{ replica_dns }} --password={{ipa_password}}
--no-wait-for-dns

copied the replica file over to replica server:
scp -oStrictHostKeyChecking=no -i ~/.ssh/{{ssh_keyname}}.pem
/var/lib/ipa/replica-info-{{ replica_dns }}.gpg root@{{
replica_dns }}:/var/lib/ipa/

ran the replica install on the replica server:
ipa-replica-install /var/lib/ipa/replica-info-{{  replica_dns }}.gpg
--password={{ipa_password}} --admin-password={{ipa_password}}

I have notices that if i directly use the replica (bypassing proxy)  URL
then the objects shows after waiting for over a minute or so. When i use
proxy pass then it just times out after few seconds.

No clue why its behaving like this

Many Thanks,
Deepak

On Wed, Feb 1, 2017 at 6:45 PM, Martin Babinsky > wrote:

On 02/01/2017 11:17 AM, deepak dimri wrote:

Hello Martin, Thank you so much for your reply.

I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary
server and
its pointing to its own hostname and not to primary server
hostname :(

any other clue, Martin?

I have tried without proxy and again to luck either its throwing
same
gateway_error

Regards,
Deepak

On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky

>> wrote:

On 02/01/2017 10:22 AM, deepak dimri wrote:

Hi All,

I have two IPA servers - primary and secondary running. the
secondary
ipa server is installed using ipa replica image of primary.
While doing
the testing i realised that when i manually shut down my
primary ipa
server making my secondary server to serve the UI. And
now when
i try to
access user or hosts details using my secondary server
then i am
getting
below error in the UI. I am able to login fine though; it is
just that
when i double click on host objects then i get the error.


  An error has occurred (GATEWAY_TIMEOUT)


I am still trying to troubleshoot as why i am getting
timeout
error but
thought of asking the group here to see if some one can
share
some pointers

Many Thanks,
Deepak


Hi Deepak,

please check /etc/ipa/default.conf on the secondary server
and check
the value of 'xmlrpc_uri'. Maybe it points to the URL of primary
server and that's why you get timeouts when it is down.

Re-setting it to the secondary server itself should fix it.

--
Martin^3 Babinsky

--
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



Adding freeipa-users back to loop.

That is strange, how did you stand up the replica?

You can also inspect /var/log/http/error_log on the replica to see
whether the commands from the WebUI reach the local HTTP server at all.

--
Martin^3 Babinsky




Deepak,

please keep replying to freeipa-users mailing list, otherwise other 
members do not get updates on your problem.


As for the issues with replica, I did not notice before that you are 
connecting to WebUI through a proxy, what kind of proxy is that and how 
is it configured?


Nevertheless waiting for over a minute to display entries does not sound 
right. I would investigate the root cause of this performance regression 
by checking DS access and error logs on the replica 
(/var/log/dirsrv/slapd-$YOUR_REALM/{access,errors}).


Does the master also take so long time to respond? What are the IPA 
versions of master/replica?


--
Martin^3 Babinsky

--
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] caching of lookups / performance problem

[Sullivan, Daniel [CRI]]

Alright cool, thank you for getting back to me.  I appreciate your input and 
expertise.

Dan

> On Feb 1, 2017, at 9:08 AM, Jakub Hrozek  wrote:
> 
> On Wed, Feb 01, 2017 at 02:35:00PM +, Sullivan, Daniel [CRI] wrote:
>> Jakub,
>> 
>> Thank you for getting back to me.  Yeah, I agree with what you are saying.  
>> The problem that I’m really trying to solve is the how to get them requested 
>> reasonably often part.  A good use case for my problem is basically;
>> 
>> 1) Somebody starts an interactive job on a compute node (this is somewhat 
>> unusual in it of itself).  There’s a decent chance that nobody has done this 
>> for weeks or months months in the first place.  Since a large number of our 
>> 1000 or so users aren’t compute users theres a high probablity that we have 
>> a substantial number of expired cached entries, possibly 500 or more for 
>> users in /home.
>> 2) They are navigating around on the filesystem and cd into /home and type 
>> ‘ls -l’
>> 
>> This command will actually take upwards of an hour to execute (although it 
>> will complete eventually).  If an ‘ls -l’ on a Linux system takes more than 
>> a few seconds people will think there’s a problem with the system.
>> 
>> Based on my experience even ‘nowait percentage’ has a difficult time with a 
>> large number of records past the nowait threshold.  For example, if there 
>> are 500 records past the expiration percentage threshold, the data provider 
>> will get ‘busy’ which seems to effectively appears to block the nss 
>> responder, instead of returning all 500 of those records from the cache and 
>> then queueing 500 data provider requests in the background to refresh the 
>> cache.
> 
> Yes, when the cache is totally expired, the request would block.
> 
>> 
>> Right now the only ways I can seem to get around this is to do a regular ‘ls 
>> -l’ to refresh the cache on our nodes, or just defer the problem by setting 
>> a really high entry cache timeout.  The cron approach is a little bit 
>> challenging because we need to randomize invocation times because bulk cache 
>> refreshes across the environment are going to cause high load on our domain 
>> controllers (I know this because a single cache refresh causes ns-slapd to 
>> hit 100% and sustain CPU utilization for the duration of the enumeration).
>> 
>> Is there anything crazy about setting the entry cache timeout on the client 
>> to something arbitrarily high, like 5 years (other than knowing the cache is 
>> not accurate)?  Based on my knowledge a user’s groups are evaluated at login 
>> so this should be a non-issue from a security standpoint.
> 
> I think a long expiration together with the nowait percentage might be
> a way to go.


-- 
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] caching of lookups / performance problem

[Jakub Hrozek]

On Wed, Feb 01, 2017 at 02:35:00PM +, Sullivan, Daniel [CRI] wrote:
> Jakub,
> 
> Thank you for getting back to me.  Yeah, I agree with what you are saying.  
> The problem that I’m really trying to solve is the how to get them requested 
> reasonably often part.  A good use case for my problem is basically;
> 
> 1) Somebody starts an interactive job on a compute node (this is somewhat 
> unusual in it of itself).  There’s a decent chance that nobody has done this 
> for weeks or months months in the first place.  Since a large number of our 
> 1000 or so users aren’t compute users theres a high probablity that we have a 
> substantial number of expired cached entries, possibly 500 or more for users 
> in /home.
> 2) They are navigating around on the filesystem and cd into /home and type 
> ‘ls -l’
> 
> This command will actually take upwards of an hour to execute (although it 
> will complete eventually).  If an ‘ls -l’ on a Linux system takes more than a 
> few seconds people will think there’s a problem with the system.
> 
> Based on my experience even ‘nowait percentage’ has a difficult time with a 
> large number of records past the nowait threshold.  For example, if there are 
> 500 records past the expiration percentage threshold, the data provider will 
> get ‘busy’ which seems to effectively appears to block the nss responder, 
> instead of returning all 500 of those records from the cache and then 
> queueing 500 data provider requests in the background to refresh the cache.

Yes, when the cache is totally expired, the request would block.

> 
> Right now the only ways I can seem to get around this is to do a regular ‘ls 
> -l’ to refresh the cache on our nodes, or just defer the problem by setting a 
> really high entry cache timeout.  The cron approach is a little bit 
> challenging because we need to randomize invocation times because bulk cache 
> refreshes across the environment are going to cause high load on our domain 
> controllers (I know this because a single cache refresh causes ns-slapd to 
> hit 100% and sustain CPU utilization for the duration of the enumeration).
> 
> Is there anything crazy about setting the entry cache timeout on the client 
> to something arbitrarily high, like 5 years (other than knowing the cache is 
> not accurate)?  Based on my knowledge a user’s groups are evaluated at login 
> so this should be a non-issue from a security standpoint.

I think a long expiration together with the nowait percentage might be
a way to go.

-- 
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] Identification with openLDAP and authorization with FreeIPA

[Michaël Van de Borne]

Ok, thank you very much guys for your ideas.

That's why I definitely love open source... :)


Cheers,

m.

Le 01-02-17 à 09:04, Michael Ströder a écrit :

Alexander Bokovoy wrote:

On ti, 31 tammi 2017, Rich Megginson wrote:

On 01/31/2017 04:46 PM, Michaël Van de Borne wrote:

That was the feared, but somehow expected, answer.

Any entry point/documentation about how to start such a script?

Do FreeIPA and OpenLDAP still support the syncrepl protocol?

a standard syncrepl provider/consumer pair expects to have the very same
LDAP schema on both sides. This is not the case with OpenLDAP and
FreeIPA.

Yes.

Another option would be to implement a custom syncrepl client which is of 
course a lot of
work to get it right.

Ciao, Michael.






-- 
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] caching of lookups / performance problem

[Sullivan, Daniel [CRI]]

Jakub,

Thank you for getting back to me.  Yeah, I agree with what you are saying.  The 
problem that I’m really trying to solve is the how to get them requested 
reasonably often part.  A good use case for my problem is basically;

1) Somebody starts an interactive job on a compute node (this is somewhat 
unusual in it of itself).  There’s a decent chance that nobody has done this 
for weeks or months months in the first place.  Since a large number of our 
1000 or so users aren’t compute users theres a high probablity that we have a 
substantial number of expired cached entries, possibly 500 or more for users in 
/home.
2) They are navigating around on the filesystem and cd into /home and type ‘ls 
-l’

This command will actually take upwards of an hour to execute (although it will 
complete eventually).  If an ‘ls -l’ on a Linux system takes more than a few 
seconds people will think there’s a problem with the system.

Based on my experience even ‘nowait percentage’ has a difficult time with a 
large number of records past the nowait threshold.  For example, if there are 
500 records past the expiration percentage threshold, the data provider will 
get ‘busy’ which seems to effectively appears to block the nss responder, 
instead of returning all 500 of those records from the cache and then queueing 
500 data provider requests in the background to refresh the cache.

Right now the only ways I can seem to get around this is to do a regular ‘ls 
-l’ to refresh the cache on our nodes, or just defer the problem by setting a 
really high entry cache timeout.  The cron approach is a little bit challenging 
because we need to randomize invocation times because bulk cache refreshes 
across the environment are going to cause high load on our domain controllers 
(I know this because a single cache refresh causes ns-slapd to hit 100% and 
sustain CPU utilization for the duration of the enumeration).

Is there anything crazy about setting the entry cache timeout on the client to 
something arbitrarily high, like 5 years (other than knowing the cache is not 
accurate)?  Based on my knowledge a user’s groups are evaluated at login so 
this should be a non-issue from a security standpoint.

Dan



> On Feb 1, 2017, at 1:55 AM, Jakub Hrozek  wrote:
> 
> On Tue, Jan 31, 2017 at 08:05:18PM +, Sullivan, Daniel [CRI] wrote:
>> Hi,
>> 
>> I figured out what was going on with this issue.  Basically cache timeouts 
>> were causing a large number of uid numbers in an arbitrarily-timed directory 
>> listing to have expired cache records, which causes those records to be 
>> looked up again by the data provider (and thus blocking ‘ls -l’).  To work 
>> around this issue now we currently setting the entry_cache_timeout to 
>> something arbitrarily high, i.e. 99, I’m questioning whether or not this 
>> is the best approach.  I’d like to use something like 
>> refresh_expired_interval, although based on my testing it appears that this 
>> does not update records for a trusted AD domain.  I’ve also tried using 
>> enumeration, and that doesn’t seem to work either.
>> 
>> I suppose my question is this; is there a preferred method to keep cache 
>> records up-to-date for a trusted AD domain?  Right now I am thinking about 
>> cron-tabbing an ‘ls -l’ of /home and allowing entry_cache_nowait_percentage 
>> to fill this function, although that seems hacky to me.
>> 
>> Any advisement that could be provided would be greatly appreciated.
> 
> Hi,
> 
> If the entries are requested reasonably often (typically at least once
> per cache lifetime), then maybe just lowering the
> 'entry_cache_nowait_percentage' value so that the background check is
> performed more often might help.
> 
> -- 
> 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] Needs help understand this timeout issue

[Sullivan, Daniel [CRI]]

Have you checked to see if the user is expired in the cache, or if it is 
impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry 
timeout is only 90 minutes and entry_cache_nowait_percentage default is 50.

ldbsearch -H  /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb > 
~/timestamps.txt
ldbsearch -H  /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt

Might be able to provide more info.

Again, I’d really familiarize yourself with the anatomy of an sssd lookup, if 
you get to know the diagram and steps 1-7 here it will be a big help to your 
question(s).  
https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/

Dan


> On Feb 1, 2017, at 4:32 AM, Troels Hansen  wrote:
> 
>> From looking af at TCP dump, I can see that if a client requests a AD user 
>> from IPA, IPA does a full user lookup in AD, even though the IPA server have 
>> the user in local cache?
> 
> It looks like a single group generates a LOT of traffic to AD like:
> client -> IPA
> IPA -> client
> IPA -> AD
> AD -> IPA
> IPA -> AD
> IPA -> Second AD
> Second AD -> IPA
> IPA -> Second AD
> IPA -> AD
> AD -> IPA
> IPA -> AD
> IPA -> client
> client -> IPA
> IPA -> Client
> 
> Something similar continues for every group the user has.
> 
> Soo, I guess the question that I haven't been able to find documented 
> anywhere. 
> Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd 
> client requests a user?
> 
> 
> 
> - On Feb 1, 2017, at 9:53 AM, Troels Hansen t...@casalogic.dk wrote:
> 
>> Hmm, suspect its happening on the server.. thous I haven't been able to
>> pinpoint a log entry that confirms my suspecting.
>> 
>> I have pinpointed the timeout to happen after 58 seconds after completely
>> removing the SSSD cache and restaring SSSD, which leads me to think my issue 
>> is
>> related to ldap_enumaration_search_timeout which defaults to 60.
>> 
>> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja
>> 
>> However, I'm unable to crank it up on the server as it seems to be adjusted 
>> Down
>> to 60 Again?
>> 
>> Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): 
>> Option
>> ldap_enumeration_search_timeout has value 120
>> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
>> (0x0400):
>> Option ldap_enumeration_search_timeout has value 60
>> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
>> (0x0400):
>> Option ldap_enumeration_search_timeout has value 60
>> 
>> LDAP seems speedy enough, not timeouts while querying it manually while a 
>> client
>> is doing a user lookup.
>> 
>> - On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI]
>> dsulliv...@bsd.uchicago.edu wrote:
>> 
>>> 
>>> If the timeout is occurring on the server, I would start by increasing one 
>>> or
>>> both of these values:
>>> 
>>> ldap_opt_timeout
>>> ldap_search_timeout
>>> 
>>> If that doesn’t work I’d take look to see if the 389 server is under high 
>>> load
>>> when you are performing this operation.  The easiest way I have found to do
>>> this is to just execute an LDAP query directly against the IPA server when 
>>> you
>>> are performing an id lookup, for example:
>>> 
>>> ldapsearch -D "cn=Directory Manager" -w  -s base -b "cn=config"
>>> "(objectclass=*)”
>>> 
>>> If the LDAP server is not responsive you probably need to increase the 
>>> number of
>>> worker threads for 389ds.  Also, you might want to disable referrals, check 
>>> out
>>> the man pages for this;
>>> 
>>> ldap_referrals = false
>>> 
>>> Also, FWIW, if you crank up debug logging on the sssd client, you should be 
>>> able
>>> to see the amount of seconds of timeout assigned to the operation, and 
>>> witness
>>> the fact that the operation is actually timing out by inspecting the logs
>>> themselves.  The logs can get a little verbose but the data is there.
>>> 
>> 
>> --
>> 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
> 
> -- 
> Med venlig hilsen 
> 
> Troels Hansen 
> 
> Systemkonsulent 
> 
> Casalogic A/S 
> 
> 
> T (+45) 70 20 10 63 
> 
> M (+45) 22 43 71 57 
> 
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
> meget mere.
> 
> -- 
> 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] Replica FQDN / Domain question

[Martin Basti]

On 01.02.2017 14:06, Christophe TREFOIS wrote:

Hi all,

Small question which might be naive.

We have an existing setup with 4 replicas, all with FQDNs like 
replica1.example.com  and REALM 
example.com .


We want to add another replica, replica5, whose FQDN would have a 
different domain, so say replica5.example.org 
.
The DNS would be resolvable as it would be managed by the same DNS 
server (outside of our control).


We don’t think this should have any impact.

Is this a fair assumption? We just want to make sure.

Kind regards,
Christophe


It should work, but keep on mind that replica5 will be still part of 
realm EXAMPLE.COM


Martin
-- 
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] Needs help understand this timeout issue

[Sullivan, Daniel [CRI]]

The  ldap_enumeration_search_timeout is for enumeration, this is for looking up 
all users, try using the ldap_opt_timeout and or ldap_opt_timeout for a single 
user lookup.  If a lookup is timing out you will definitely see it in your 
domain logs, it’s hard to miss.

I would take the time to familiarize yourself at a minimum with the following 
two articles:

https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/

Also, this is very good document to familiarize yourself with, it has a lot of 
very detailed and use information.

https://fedorahosted.org/sssd/wiki/InternalsDocs

My personal opinion based on experience is that if you are going to be 
leveraging sssd in a trusted AD setup, you should be prepared to take on 
performance tuning considerations and become intimately familiar with the 
internals of sssd, specifically how a lookup works, and how to tune sssd as 
well as 389ds.  You should know the difference between the mapped memory cache, 
the sysdb, how to use ldbsearch to inspect the cache, etc.  The learning curve 
is a little steep but once you get over it it’s not that bad. 

Dan

> On Feb 1, 2017, at 2:53 AM, Troels Hansen  wrote:
> 
> Hmm, suspect its happening on the server.. thous I haven't been able to 
> pinpoint a log entry that confirms my suspecting.
> 
> I have pinpointed the timeout to happen after 58 seconds after completely 
> removing the SSSD cache and restaring SSSD, which leads me to think my issue 
> is related to ldap_enumaration_search_timeout which defaults to 60.
> 
> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja
> 
> However, I'm unable to crank it up on the server as it seems to be adjusted 
> Down to 60 Again?
> 
> Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): 
> Option ldap_enumeration_search_timeout has value 120
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
> (0x0400): Option ldap_enumeration_search_timeout has value 60
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
> (0x0400): Option ldap_enumeration_search_timeout has value 60
> 
> LDAP seems speedy enough, not timeouts while querying it manually while a 
> client is doing a user lookup.
> 
> - On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] 
> dsulliv...@bsd.uchicago.edu wrote:
> 
>> 
>> If the timeout is occurring on the server, I would start by increasing one or
>> both of these values:
>> 
>> ldap_opt_timeout
>> ldap_search_timeout
>> 
>> If that doesn’t work I’d take look to see if the 389 server is under high 
>> load
>> when you are performing this operation.  The easiest way I have found to do
>> this is to just execute an LDAP query directly against the IPA server when 
>> you
>> are performing an id lookup, for example:
>> 
>> ldapsearch -D "cn=Directory Manager" -w  -s base -b "cn=config"
>> "(objectclass=*)”
>> 
>> If the LDAP server is not responsive you probably need to increase the 
>> number of
>> worker threads for 389ds.  Also, you might want to disable referrals, check 
>> out
>> the man pages for this;
>> 
>> ldap_referrals = false
>> 
>> Also, FWIW, if you crank up debug logging on the sssd client, you should be 
>> able
>> to see the amount of seconds of timeout assigned to the operation, and 
>> witness
>> the fact that the operation is actually timing out by inspecting the logs
>> themselves.  The logs can get a little verbose but the data is there.
>> 


-- 
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] Gateway_timeout Error

[Martin Babinsky]

On 02/01/2017 11:17 AM, deepak dimri wrote:

Hello Martin, Thank you so much for your reply.

I checked /etc/ipa/default.conf 'xmlrpc_uri' on my secondary server and
its pointing to its own hostname and not to primary server hostname :(

any other clue, Martin?

I have tried without proxy and again to luck either its throwing same
gateway_error

Regards,
Deepak

On Wed, Feb 1, 2017 at 3:03 PM, Martin Babinsky > wrote:

On 02/01/2017 10:22 AM, deepak dimri wrote:

Hi All,

I have two IPA servers - primary and secondary running. the
secondary
ipa server is installed using ipa replica image of primary.
While doing
the testing i realised that when i manually shut down my primary ipa
server making my secondary server to serve the UI. And now when
i try to
access user or hosts details using my secondary server then i am
getting
below error in the UI. I am able to login fine though; it is
just that
when i double click on host objects then i get the error.


  An error has occurred (GATEWAY_TIMEOUT)


I am still trying to troubleshoot as why i am getting timeout
error but
thought of asking the group here to see if some one can share
some pointers

Many Thanks,
Deepak


Hi Deepak,

please check /etc/ipa/default.conf on the secondary server and check
the value of 'xmlrpc_uri'. Maybe it points to the URL of primary
server and that's why you get timeouts when it is down.

Re-setting it to the secondary server itself should fix it.

--
Martin^3 Babinsky

--
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




Adding freeipa-users back to loop.

That is strange, how did you stand up the replica?

You can also inspect /var/log/http/error_log on the replica to see 
whether the commands from the WebUI reach the local HTTP server at all.


--
Martin^3 Babinsky

--
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] Replica FQDN / Domain question

[Christophe TREFOIS]

Hi all,

Small question which might be naive.

We have an existing setup with 4 replicas, all with FQDNs like 
replica1.example.com and REALM 
example.com.

We want to add another replica, replica5, whose FQDN would have a different 
domain, so say replica5.example.org.
The DNS would be resolvable as it would be managed by the same DNS server 
(outside of our control).

We don’t think this should have any impact.

Is this a fair assumption? We just want to make sure.

Kind regards,
Christophe
-- 
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] Needs help understand this timeout issue

[Troels Hansen]

>From looking af at TCP dump, I can see that if a client requests a AD user 
>from IPA, IPA does a full user lookup in AD, even though the IPA server have 
>the user in local cache?

It looks like a single group generates a LOT of traffic to AD like:
client -> IPA
IPA -> client
IPA -> AD
AD -> IPA
IPA -> AD
IPA -> Second AD
Second AD -> IPA
IPA -> Second AD
IPA -> AD
AD -> IPA
IPA -> AD
IPA -> client
client -> IPA
IPA -> Client

Something similar continues for every group the user has.

Soo, I guess the question that I haven't been able to find documented anywhere. 
Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd 
client requests a user?



- On Feb 1, 2017, at 9:53 AM, Troels Hansen t...@casalogic.dk wrote:

> Hmm, suspect its happening on the server.. thous I haven't been able to
> pinpoint a log entry that confirms my suspecting.
> 
> I have pinpointed the timeout to happen after 58 seconds after completely
> removing the SSSD cache and restaring SSSD, which leads me to think my issue 
> is
> related to ldap_enumaration_search_timeout which defaults to 60.
> 
> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja
> 
> However, I'm unable to crank it up on the server as it seems to be adjusted 
> Down
> to 60 Again?
> 
> Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): 
> Option
> ldap_enumeration_search_timeout has value 120
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400):
> Option ldap_enumeration_search_timeout has value 60
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400):
> Option ldap_enumeration_search_timeout has value 60
> 
> LDAP seems speedy enough, not timeouts while querying it manually while a 
> client
> is doing a user lookup.
> 
> - On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI]
> dsulliv...@bsd.uchicago.edu wrote:
> 
>> 
>> If the timeout is occurring on the server, I would start by increasing one or
>> both of these values:
>> 
>> ldap_opt_timeout
>> ldap_search_timeout
>> 
>> If that doesn’t work I’d take look to see if the 389 server is under high 
>> load
>> when you are performing this operation.  The easiest way I have found to do
>> this is to just execute an LDAP query directly against the IPA server when 
>> you
>> are performing an id lookup, for example:
>> 
>> ldapsearch -D "cn=Directory Manager" -w  -s base -b "cn=config"
>> "(objectclass=*)”
>> 
>> If the LDAP server is not responsive you probably need to increase the 
>> number of
>> worker threads for 389ds.  Also, you might want to disable referrals, check 
>> out
>> the man pages for this;
>> 
>> ldap_referrals = false
>> 
>> Also, FWIW, if you crank up debug logging on the sssd client, you should be 
>> able
>> to see the amount of seconds of timeout assigned to the operation, and 
>> witness
>> the fact that the operation is actually timing out by inspecting the logs
>> themselves.  The logs can get a little verbose but the data is there.
>>
> 
> --
> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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] Gateway_timeout Error

[Martin Babinsky]

On 02/01/2017 10:22 AM, deepak dimri wrote:

Hi All,

I have two IPA servers - primary and secondary running. the secondary
ipa server is installed using ipa replica image of primary.  While doing
the testing i realised that when i manually shut down my primary ipa
server making my secondary server to serve the UI. And now when i try to
access user or hosts details using my secondary server then i am getting
below error in the UI. I am able to login fine though; it is just that
when i double click on host objects then i get the error.


  An error has occurred (GATEWAY_TIMEOUT)


I am still trying to troubleshoot as why i am getting timeout error but
thought of asking the group here to see if some one can share some pointers

Many Thanks,
Deepak



Hi Deepak,

please check /etc/ipa/default.conf on the secondary server and check the 
value of 'xmlrpc_uri'. Maybe it points to the URL of primary server and 
that's why you get timeouts when it is down.


Re-setting it to the secondary server itself should fix it.

--
Martin^3 Babinsky

--
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] Gateway_timeout Error

[deepak dimri]

Hi All,

I have two IPA servers - primary and secondary running. the secondary ipa
server is installed using ipa replica image of primary.  While doing the
testing i realised that when i manually shut down my primary ipa server
making my secondary server to serve the UI. And now when i try to access
user or hosts details using my secondary server then i am getting below
error in the UI. I am able to login fine though; it is just that when i
double click on host objects then i get the error.
An error has occurred (GATEWAY_TIMEOUT)

I am still trying to troubleshoot as why i am getting timeout error but
thought of asking the group here to see if some one can share some pointers

Many Thanks,
Deepak
-- 
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] Needs help understand this timeout issue

[Troels Hansen]

Hmm, suspect its happening on the server.. thous I haven't been able to 
pinpoint a log entry that confirms my suspecting.

I have pinpointed the timeout to happen after 58 seconds after completely 
removing the SSSD cache and restaring SSSD, which leads me to think my issue is 
related to ldap_enumaration_search_timeout which defaults to 60.

rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja

However, I'm unable to crank it up on the server as it seems to be adjusted 
Down to 60 Again?

Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): 
Option ldap_enumeration_search_timeout has value 120
(Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): 
Option ldap_enumeration_search_timeout has value 60
(Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): 
Option ldap_enumeration_search_timeout has value 60

LDAP seems speedy enough, not timeouts while querying it manually while a 
client is doing a user lookup.

- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] 
dsulliv...@bsd.uchicago.edu wrote:

> 
> If the timeout is occurring on the server, I would start by increasing one or
> both of these values:
> 
> ldap_opt_timeout
> ldap_search_timeout
> 
> If that doesn’t work I’d take look to see if the 389 server is under high load
> when you are performing this operation.  The easiest way I have found to do
> this is to just execute an LDAP query directly against the IPA server when you
> are performing an id lookup, for example:
> 
> ldapsearch -D "cn=Directory Manager" -w  -s base -b "cn=config"
> "(objectclass=*)”
> 
> If the LDAP server is not responsive you probably need to increase the number 
> of
> worker threads for 389ds.  Also, you might want to disable referrals, check 
> out
> the man pages for this;
> 
> ldap_referrals = false
> 
> Also, FWIW, if you crank up debug logging on the sssd client, you should be 
> able
> to see the amount of seconds of timeout assigned to the operation, and witness
> the fact that the operation is actually timing out by inspecting the logs
> themselves.  The logs can get a little verbose but the data is there.
>

-- 
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] Identification with openLDAP and authorization with FreeIPA

[Michael Ströder]

Alexander Bokovoy wrote:
> On ti, 31 tammi 2017, Rich Megginson wrote:
>> On 01/31/2017 04:46 PM, Michaël Van de Borne wrote:
>>> That was the feared, but somehow expected, answer.
>>>
>>> Any entry point/documentation about how to start such a script?
>>
>> Do FreeIPA and OpenLDAP still support the syncrepl protocol?
>
> a standard syncrepl provider/consumer pair expects to have the very same
> LDAP schema on both sides. This is not the case with OpenLDAP and
> FreeIPA.

Yes.

Another option would be to implement a custom syncrepl client which is of 
course a lot of
work to get it right.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic 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] caching of lookups / performance problem

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 08:05:18PM +, Sullivan, Daniel [CRI] wrote:
> Hi,
> 
> I figured out what was going on with this issue.  Basically cache timeouts 
> were causing a large number of uid numbers in an arbitrarily-timed directory 
> listing to have expired cache records, which causes those records to be 
> looked up again by the data provider (and thus blocking ‘ls -l’).  To work 
> around this issue now we currently setting the entry_cache_timeout to 
> something arbitrarily high, i.e. 99, I’m questioning whether or not this 
> is the best approach.  I’d like to use something like 
> refresh_expired_interval, although based on my testing it appears that this 
> does not update records for a trusted AD domain.  I’ve also tried using 
> enumeration, and that doesn’t seem to work either.
> 
> I suppose my question is this; is there a preferred method to keep cache 
> records up-to-date for a trusted AD domain?  Right now I am thinking about 
> cron-tabbing an ‘ls -l’ of /home and allowing entry_cache_nowait_percentage 
> to fill this function, although that seems hacky to me.
> 
> Any advisement that could be provided would be greatly appreciated.

Hi,

If the entries are requested reasonably often (typically at least once
per cache lifetime), then maybe just lowering the
'entry_cache_nowait_percentage' value so that the background check is
performed more often might help.

-- 
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