[Freeipa-users] errors when adding a new server

[Andrew Meyer via FreeIPA-users]

So I rebuilt a server tonight and gave it a new hostname but i'm getting the 
following error when trying to add the new one.  

Skip ipa.domain.local: cannot verify if this is an IPA server
Provide your IPA server name (ex: ipa.example.com): ipa.domain.local
Skip ipa.domain.local: cannot verify if this is an IPA server
Failed to verify that ipa.domain.local is an IPA Server.
This may mean that the remote server is not up or is not reachable due to 
network or firewall settings.

There is nothing in the logs in /var/log.  However when I run systemctl I see 
that the IPA service exited.  But I can tell why.
The last thing I did was reboot the IPA server.  This is a single IPA server 
domain setup running on CentOS 7.4 latest version of FreeIPA.


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: user/admin

[Alexander Bokovoy via FreeIPA-users]

On ma, 19 helmi 2018, Charles Hedrick wrote:

From the point of view of managing users, it would be nice to be able
to add it as a secondary principal for the user. It’s not important
enough for a major implementation effort.

We already support adding principal aliases:

 kinit admin
 ipa user-add-principal foo foo/ad...@example.com

However, this is not going to be useful because while KDC will accept
foo/admin principal in AS-REQ, a returned ticket will be issued in the
canonical name of the principal (foo). A client has to be prepared for
that: while kinit has option for canonicalization, kadmin doesn't.

$ kinit abokovoy/admin
Password for abokovoy/ad...@example.com: 
$ klist -A

Ticket cache: KEYRING:persistent:980138753:krb_ccache_LT6Pbr6
Default principal: aboko...@example.com

Valid starting   Expires  Service principal
19.02.2018 22.48.34  20.02.2018 22.48.30  krbtgt/example@example.com

$ kadmin
Authenticating as principal abokovoy/ad...@example.com with password.
Password for abokovoy/ad...@example.com: 
kadmin: KDC reply did not match expectations while initializing kadmin interface


The response from kadmin is exactly this: kadmin client doesn't support
canonicalization.

Using GSSAPI authentication with a TGT obtained using Kerberos principal alias
will not be different from using a canonical name for the same principal:
neither acceptor nor initiator will  mention an aliased principal name; it only
is usable with kinit. There is no real benefit in having this kind of alias for
user principals (on contrary, Kerberos principal aliases are very useful for
services as targets).

Note that the behavior demonstrated above is the same with other Kerberos
systems that support aliases. This is a protocol behavior.




On Feb 19, 2018, at 4:11 PM, Charles Hedrick via FreeIPA-users 
 wrote:

Several staff and I have separate principals that we use for privileged
operations. Rather than completely separate users I would prefer things like
hedrick/admin, where it’s immediately obvious that they’re connected. In
general I don’t see why IPA should prevent me from using perfectly legal
principals.

Each IPA user is a separate principal. In traditional Kerberos setup each
hedrick and hedrick/admin are different principals too. They aren't the same,
singular, user, they are completely different principals that happen to have
the same password associated with them. Since Kerberos deals with principals
only, there are no identities associated with them in Kerberos perspective; any
such identity is beyond Kerberos world. IPA extends this by making sure that
each separate principal is a separate identity too: a user, a service, a host,
etc.

Making two separate principals comprise of the same identity theoretically is
possible but practically is harder to implement than one identity per
principal.



On Feb 15, 2018, at 3:34 AM, Alexander Bokovoy  wrote:

On ke, 14 helmi 2018, Charles Hedrick via FreeIPA-users wrote:

I have two identifies, one a normal user and one with privileges in
IPA. The normal Kerberos convention is for them to be hedrick and
hedrick/admin.

This convention is only used in the Kerberos world because there is a
particular issue with kadmin protocol/implementations: they do not allow
dynamic access control. Instead, a static access control is set up with
kadm5.acl file so it became customary to set ACL once and for everyone
with something like

*/admin *

Which allows /admin principal to perform all allowed kadmin
operations except extraction of the principal's keys.

Due to a lack of any API inside kadmin that would have allowed a KDB
driver to see who is accessing the principal data, we cannot really
implement real access controls in IPA for it too.

In FreeIPA we don't really need to allow direct kadmin use because most
of its tasks can be done through IPA CLI/Web UI already, so the need for
*/admin-like names is reduced.

Do you have any other need for it?




On Feb 13, 2018, at 5:03 PM, Rob Crittenden  wrote:

Charles Hedrick via FreeIPA-users wrote:

There’s a convention of creating admin instances for users, usually named 
user/admin. IPA doesn’t seem to allow such instances. Is there a way to make 
them work?

As far as I can tell the instance can only be a hostname. That doesn’t seem 
like a sensible restriction.


To be used for what purpose?

rob


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


--
/ Alexander Bokovoy


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org




--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- 

[Freeipa-users] Re: FreeIPA integrated DNS or Bind

[Rob Crittenden via FreeIPA-users]

Ben Archuleta via FreeIPA-users wrote:
> Hello Everybody,
> 
> I am currently rolling out a FreeIPA based solution to replace a NIS behind a 
> NAT that’s deteriorating. As I look at the implementation of FreeIPA I was 
> wondering, is it better to use the DNS server thats part of FreeIPA or to use 
> Bind. The new NAT doesn’t yet have a set design so I can implement DNS in 
> whatever form is necessary. 
> 
> Topology:
> 
> NAT: x.my.wonderful.domain
> IPA:ipa0.my.wonderful.domian
> IPA:ipa1.my.wonderful.domain
> 
> Then 250 workstations live behind the NAT.

I don't know that one is better than another. Integrated DNS can make
some things easier like automatically creating and managing the SRV
entries needed for autodiscovery but many users manage DNS outside of IPA.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: user/admin

[Charles Hedrick via FreeIPA-users]

From the point of view of managing users, it would be nice to be able to add it 
as a secondary principal for the user. It’s not important enough for a major 
implementation effort.

> On Feb 19, 2018, at 4:11 PM, Charles Hedrick via FreeIPA-users 
>  wrote:
> 
> Several staff and I have separate principals that we use for privileged 
> operations. Rather than completely separate users I would prefer things like 
> hedrick/admin, where it’s immediately obvious that they’re connected. In 
> general I don’t see why IPA should prevent me from using perfectly legal 
> principals.
> 
>> On Feb 15, 2018, at 3:34 AM, Alexander Bokovoy  wrote:
>> 
>> On ke, 14 helmi 2018, Charles Hedrick via FreeIPA-users wrote:
>>> I have two identifies, one a normal user and one with privileges in
>>> IPA. The normal Kerberos convention is for them to be hedrick and
>>> hedrick/admin.
>> This convention is only used in the Kerberos world because there is a
>> particular issue with kadmin protocol/implementations: they do not allow
>> dynamic access control. Instead, a static access control is set up with
>> kadm5.acl file so it became customary to set ACL once and for everyone
>> with something like
>> 
>> */admin *
>> 
>> Which allows /admin principal to perform all allowed kadmin
>> operations except extraction of the principal's keys.
>> 
>> Due to a lack of any API inside kadmin that would have allowed a KDB
>> driver to see who is accessing the principal data, we cannot really
>> implement real access controls in IPA for it too.
>> 
>> In FreeIPA we don't really need to allow direct kadmin use because most
>> of its tasks can be done through IPA CLI/Web UI already, so the need for
>> */admin-like names is reduced.
>> 
>> Do you have any other need for it?
>> 
>>> 
 On Feb 13, 2018, at 5:03 PM, Rob Crittenden  wrote:
 
 Charles Hedrick via FreeIPA-users wrote:
> There’s a convention of creating admin instances for users, usually named 
> user/admin. IPA doesn’t seem to allow such instances. Is there a way to 
> make them work?
> 
> As far as I can tell the instance can only be a hostname. That doesn’t 
> seem like a sensible restriction.
 
 To be used for what purpose?
 
 rob
>>> 
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>> 
>> -- 
>> / Alexander Bokovoy
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: user/admin

[Charles Hedrick via FreeIPA-users]

Several staff and I have separate principals that we use for privileged 
operations. Rather than completely separate users I would prefer things like 
hedrick/admin, where it’s immediately obvious that they’re connected. In 
general I don’t see why IPA should prevent me from using perfectly legal 
principals.

> On Feb 15, 2018, at 3:34 AM, Alexander Bokovoy  wrote:
> 
> On ke, 14 helmi 2018, Charles Hedrick via FreeIPA-users wrote:
>> I have two identifies, one a normal user and one with privileges in
>> IPA. The normal Kerberos convention is for them to be hedrick and
>> hedrick/admin.
> This convention is only used in the Kerberos world because there is a
> particular issue with kadmin protocol/implementations: they do not allow
> dynamic access control. Instead, a static access control is set up with
> kadm5.acl file so it became customary to set ACL once and for everyone
> with something like
> 
> */admin *
> 
> Which allows /admin principal to perform all allowed kadmin
> operations except extraction of the principal's keys.
> 
> Due to a lack of any API inside kadmin that would have allowed a KDB
> driver to see who is accessing the principal data, we cannot really
> implement real access controls in IPA for it too.
> 
> In FreeIPA we don't really need to allow direct kadmin use because most
> of its tasks can be done through IPA CLI/Web UI already, so the need for
> */admin-like names is reduced.
> 
> Do you have any other need for it?
> 
>> 
>>> On Feb 13, 2018, at 5:03 PM, Rob Crittenden  wrote:
>>> 
>>> Charles Hedrick via FreeIPA-users wrote:
 There’s a convention of creating admin instances for users, usually named 
 user/admin. IPA doesn’t seem to allow such instances. Is there a way to 
 make them work?
 
 As far as I can tell the instance can only be a hostname. That doesn’t 
 seem like a sensible restriction.
>>> 
>>> To be used for what purpose?
>>> 
>>> rob
>> 
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
> -- 
> / Alexander Bokovoy

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIpa install failed on CA did not start in 300.0s

[Rob Crittenden via FreeIPA-users]

MyGmail wrote:
> Hi Rob, 
> 
> It was Apache Spark (master). 
> This was a Hadoop edge node.

Ok, I just wanted to confirm it wasn't something left by IPA in a blown
install. Thanks for checking.

I did a brief source scan and I don't think we check for availability
for 8080 (just 8443). I'll open a ticket.

rob

> 
> Regards,
> Andrey
> 
>> 19 февр. 2018 г., в 15:19, Rob Crittenden  написал(а):
>>
>> Markovich via FreeIPA-users wrote:
>>> Hi all!
>>>
>>> Finnaly found out, what was wrong.
>>>
>>> Some phantomy process was using port 8080. Killed it and every thing
>>> became fine. 
>>>
>>> It's very strange that FreIpa not checked this port for avaliablity as
>>> 389 or 686.
>>
>> What phantom process was that?
>>
>> rob
>>
>>>
>>> Regards,
>>> Andrey
>>>
>>> 2018-02-16 22:32 GMT+03:00 Markovich >> >:
>>>
>>>Hi Natxo,
>>>
>>>[root@ hostname> ~]# df -h
>>>Filesystem  Size  Used Avail Use% Mounted on
>>>/dev/sda230G   14G   17G  45% /
>>>devtmpfs7.9G 0  7.9G   0% /dev
>>>tmpfs   7.9G   16K  7.9G   1% /dev/shm
>>>tmpfs   7.9G   25M  7.9G   1% /run
>>>tmpfs   7.9G 0  7.9G   0% /sys/fs/cgroup
>>>/dev/sda1   497M   79M  419M  16% /boot
>>>tmpfs   1.6G 0  1.6G   0% /run/user/996
>>>tmpfs   1.6G 0  1.6G   0% /run/user/1012
>>>tmpfs   1.6G 0  1.6G   0% /run/user/1004
>>>/dev/sdb132G  968M   29G   4% /mnt/resource
>>>tmpfs   1.6G 0  1.6G   0% /run/user/0
>>>
>>>We have enough disk space.
>>>
>>>Also FreeIpa was installed before on this host. And worked fine. And
>>>now I've to reinstall it.
>>>
>>>Regards,
>>>Andrey
>>>
>>>
>>>2018-02-16 21:40 GMT+03:00 Natxo Asenjo via FreeIPA-users
>>>>>>:
>>>
>>>hi,
>>>
>>>
>>>On Fri, Feb 16, 2018 at 6:28 PM, Markovich via FreeIPA-users
>>>>>> wrote:
>>>
>>>Hi FreeIPA users,
>>>
>>>Please help find wat's going wrong while reinstalling freeipa...
>>>
>>>
>>>2018-02-16T16:41:30Z DEBUG response body
>>>'\n\n>>content="text/html; 405 HTTP method POST is not supported by
>>>this URL>>2018-02-16T16:41:30Z DEBUG The CA status is: check
>>>interrupted due to error: Retrieving CA status failed with
>>>status 405
>>>2018-02-16T16:41:30Z DEBUG Waiting for CA to start...
>>>2018-02-16T16:41:31Z DEBUG request POST
>>>http://:8080/ca/admin/ca/getStatus
>>>2018-02-16T16:41:31Z DEBUG request body ''
>>>2018-02-16T16:41:31Z DEBUG response status 405
>>>2018-02-16T16:41:31Z DEBUG response headers Date: Fri, 16
>>>Feb 2018 16:41:31 GMT
>>>Cache-Control: must-revalidate,no-cache,no-store
>>>Content-Type: text/html;charset=iso-8859-1
>>>Content-Length: 408
>>>Server: Jetty(9.3.z-SNAPSHOT)
>>>
>>>
>>>CA did not start in 300.0s
>>>CRITICAL Failed to restart the Dogtag instance.See the
>>>installation log for details.
>>>ERROR Unable to retrieve CA chain: Retrieving CA cert chain
>>>failed: list index out of range
>>>
>>>
>>>
>>>does your freeipa server meet the minimu requirements?
>>>
>>> (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/installing-ipa#server-hw-recomendations
>>>
>>> ).
>>>
>>>If the disk is very slow this could be a problem as well.
>>>
>>>
>>>
>>>___
>>>FreeIPA-users mailing list --
>>>freeipa-users@lists.fedorahosted.org
>>>
>>>To unsubscribe send an email to
>>>freeipa-users-le...@lists.fedorahosted.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>>>
>>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] odd DNS setting question?

[Kat via FreeIPA-users]

Good morning

What, if anything, would cause a TTL to be different in a DNS config for 
IPA?


;; ADDITIONAL SECTION:
c.example.com.   1200    IN    A    10.1.2.2
c1.example.com   1200    IN    A    10.1.2.3
p.example.com.      86400    IN    A    10.1.2.4
p1.example.com. 86400    IN    A    10.1.3.5

And yet, if I update system records, they all show the same 86400 when 
they were updated?


Question - if you are using the "location" function, would this possibly 
be related, that values are updated dynamically based on the host I am 
running "dig"  from is in a different location?


The other question is - how to keep IPA DNS from trying to forward a 
lookup.


Trying to add a replica, and Host "A" is already set as a client and 
working fine. It can only talk to IPA server "C". "C" is also set in 
resolv.conf as nameserver. When you try to add the replica however, it 
tries to resolve by way of using "c1" as the DNS resolver, which I don't 
understand why?


ipa : DEBUG    Check forward/reverse DNS resolution
ipa : DEBUG    Search DNS server c1.example.com (['10.1.2.3', 
'10.1.2.3', '10.1.2.3']) for c.example.com
ipa : ERROR    Could not resolve hostname c.example.com using 
DNS. Clients may not function properly. Please check your DNS setup. 
(Note that this check queries IPA DNS directly and ignores /etc/hosts.)


DIG works fine for resolution:

# dig +short c.example.com
10.1.2.2

So I am baffled. Is there something in DNS settings of IPA that would 
cause a server to forward to another server? (forwarding is disabled)


-K

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIpa install failed on CA did not start in 300.0s

[Rob Crittenden via FreeIPA-users]

Markovich via FreeIPA-users wrote:
> Hi all!
> 
> Finnaly found out, what was wrong.
> 
> Some phantomy process was using port 8080. Killed it and every thing
> became fine. 
> 
> It's very strange that FreIpa not checked this port for avaliablity as
> 389 or 686.

What phantom process was that?

rob

> 
> Regards,
> Andrey
> 
> 2018-02-16 22:32 GMT+03:00 Markovich  >:
> 
> Hi Natxo,
> 
> [root@ hostname> ~]# df -h
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sda2        30G   14G   17G  45% /
> devtmpfs        7.9G     0  7.9G   0% /dev
> tmpfs           7.9G   16K  7.9G   1% /dev/shm
> tmpfs           7.9G   25M  7.9G   1% /run
> tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
> /dev/sda1       497M   79M  419M  16% /boot
> tmpfs           1.6G     0  1.6G   0% /run/user/996
> tmpfs           1.6G     0  1.6G   0% /run/user/1012
> tmpfs           1.6G     0  1.6G   0% /run/user/1004
> /dev/sdb1        32G  968M   29G   4% /mnt/resource
> tmpfs           1.6G     0  1.6G   0% /run/user/0
> 
> We have enough disk space.
> 
> Also FreeIpa was installed before on this host. And worked fine. And
> now I've to reinstall it.
> 
> Regards,
> Andrey
> 
> 
> 2018-02-16 21:40 GMT+03:00 Natxo Asenjo via FreeIPA-users
>  >:
> 
> hi,
> 
> 
> On Fri, Feb 16, 2018 at 6:28 PM, Markovich via FreeIPA-users
>  > wrote:
> 
> Hi FreeIPA users,
> 
> Please help find wat's going wrong while reinstalling freeipa...
> 
> 
> 2018-02-16T16:41:30Z DEBUG response body
> '\n\n content="text/html; 405 HTTP method POST is not supported by
> this URL 2018-02-16T16:41:30Z DEBUG The CA status is: check
> interrupted due to error: Retrieving CA status failed with
> status 405
> 2018-02-16T16:41:30Z DEBUG Waiting for CA to start...
> 2018-02-16T16:41:31Z DEBUG request POST
> http://:8080/ca/admin/ca/getStatus
> 2018-02-16T16:41:31Z DEBUG request body ''
> 2018-02-16T16:41:31Z DEBUG response status 405
> 2018-02-16T16:41:31Z DEBUG response headers Date: Fri, 16
> Feb 2018 16:41:31 GMT
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Type: text/html;charset=iso-8859-1
> Content-Length: 408
> Server: Jetty(9.3.z-SNAPSHOT)
> 
> 
> CA did not start in 300.0s
> CRITICAL Failed to restart the Dogtag instance.See the
> installation log for details.
> ERROR Unable to retrieve CA chain: Retrieving CA cert chain
> failed: list index out of range
> 
> 
> 
> does your freeipa server meet the minimu requirements?
> 
> (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/installing-ipa#server-hw-recomendations
> 
> ).
> 
> If the disk is very slow this could be a problem as well.
> 
> 
> 
> ___
> FreeIPA-users mailing list --
> freeipa-users@lists.fedorahosted.org
> 
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> 
> 
> 
> 
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Fixing limit on DNS searches

[Bret Wortman via FreeIPA-users]

On 02/19/2018 07:55 AM, Florence Blanc-Renaud wrote:

On 02/19/2018 12:01 PM, Bret Wortman via FreeIPA-users wrote:

On 02/16/2018 11:54 AM, Florence Blanc-Renaud wrote:

On 02/15/2018 06:42 PM, Bret Wortman via FreeIPA-users wrote:

On 02/15/2018 12:27 PM, Florence Blanc-Renaud wrote:

On 02/15/2018 05:01 PM, Bret Wortman via FreeIPA-users wrote:

On 02/15/2018 09:29 AM, Florence Blanc-Renaud wrote:

On 02/15/2018 02:40 PM, Bret Wortman via FreeIPA-users wrote:
On 02/15/2018 07:09 AM, Florence Blanc-Renaud via FreeIPA-users 
wrote:

On 02/15/2018 11:47 AM, Bret Wortman via FreeIPA-users wrote:



On 02/15/2018 04:50 AM, Florence Blanc-Renaud wrote:
On 02/15/2018 10:08 AM, Florence Blanc-Renaud via 
FreeIPA-users wrote:

On 02/14/2018 05:58 PM, Bret Wortman wrote:

On 02/14/2018 10:22 AM, Florence Blanc-Renaud wrote:
On 02/14/2018 12:52 PM, Bret Wortman via FreeIPA-users 
wrote:

I did figure out that I can use

# ldapsearch -D 'directory manager' -W -E pr=2 -b 
idnsname=damascusgrp.com,cn=dns,dc=damascusgrp,dc=com


to list out all the entries, but the format isn't what 
I'm expecting.


What I'm actually trying to do is move our whole 
infrastructure from one set of old & busted servers to 
some shiny new VMs. We'd like to extract the data and 
start fresh, as our replication agreements just don't 
seem to be working as expected. Changes to one don't 
always make it to the other and vice versa. While I'd 
love to dig in and solve that, it's easier right now to 
try to extract the data and reload it into a new server, 
build new replicas, then unbind & re-bind every client 
to the new server using ansible since we also lost our 
internal CA in the process.


So while our current configuration is a mess, we can't 
afford to lose all the host/user/dns/hbac data in our 
servers. Thus, I've been capturing the output to text 
using various ipa *-find commands and have parsers to 
turn those back into new entries on the fresh hosts. DNS 
is the only thing that's holding me up.



Bret


On 02/14/2018 06:33 AM, Bret Wortman wrote:


Also, this doesn't solve the fact that the Web UI 
always produces an error dialog whenever accessing our 
primary zone.



On 02/13/2018 02:19 PM, Natxo Asenjo via FreeIPA-users 
wrote:



On Tue, Feb 13, 2018 at 8:13 PM, Natxo Asenjo 
> wrote:



    the canonical way to do this is using ldap paging, 
with
    ldapsearch  you could try using the -E pr= 
parameter, where
     could be 1000 for instance. That way you know 
you are always

    under the limit imposed by the server.


if you use -E pr=1000/noprompt, it will not prompt to 
continue, nicer for scripts obviously.


--
Groeten,
natxo


___
FreeIPA-users mailing list 
--freeipa-users@lists.fedorahosted.org
To unsubscribe send an email 
tofreeipa-users-le...@lists.fedorahosted.org






___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org



Hi Bret,

the search limits can be set at multiple levels:
- for the whole 389-ds server
nsslapd-sizelimit (in cn=config)
nsslapd-lookthroughlimit (in cn=config,cn=ldbm 
database,cn=plugins,cn=config)


- for operations performed through ipa * commands (or the 
webGUI):

ipaSearchRecordsLimit (in cn=ipaConfig,cn=etc,$BASEDN)

- for each user:
nssizelimit and nsLookThroughLimit attributes (in 
uid=$USER,cn=users,cn=accounts,$BASEDN)


You are probably hitting one of these limits in your ipa 
*-find command.


HTH,
Flo



So I found almost all of these:

# ldapsearch -D 'cn=directory manager' -W -b 'cn=config' 
cn=config | grep nsslapd-sizelimit

nsslapd-sizelimit: 2000

# ldapsearch -D 'cn=directory manager' -W -b 
'cn=config,cn=ldbm database,cn=plugins,cn=config' | grep 
lookthroughlimit

nsslapd-lookthroughlimit: 10

# ldapsearch -D 'cn=directory manager' -W -b 
'cn=ipaConfig,cn=etc,dc=damascusgrp,dc=com' | grep 
ipaSearchRecordsLimit

ipaSearchRecordsLimit: 9

# ldapsearch -D 'cn=directory manager' -W -b 
'uid=admin,cn=users,cn=accounts,dc=damascusgrp,dc=com' | 
grep -i limit

(returns data but nothing matches)


Hi,

nsSizeLimit and nsLookThroughLimit are operational 
attributes, meaning that a standard ldapsearch will not 
return them. You need either to specifically request them 
by providing them in the attributes list:


$ ldapsearch -D 'cn=directory manager' -W -b $BASE 
nssizelimit nslookthroughlimit


or you can also specify + instead of the attributes in 
order to get all operational attributes:

$ ldapsearch -D 'cn=directory manager' -W -b $BASE +

HTH,
Flo

The first doesn't seem to be something I can change. It's 
stuck at 2000, but since my issue occurs at 5000, I'm not 
worried about it. I believe that I'm missing something in 
the fourth search that might point me toward the 
attributes you mentioned but I'm not 

[Freeipa-users] Re: Fixing limit on DNS searches

[Florence Blanc-Renaud via FreeIPA-users]

On 02/19/2018 12:01 PM, Bret Wortman via FreeIPA-users wrote:

On 02/16/2018 11:54 AM, Florence Blanc-Renaud wrote:

On 02/15/2018 06:42 PM, Bret Wortman via FreeIPA-users wrote:

On 02/15/2018 12:27 PM, Florence Blanc-Renaud wrote:

On 02/15/2018 05:01 PM, Bret Wortman via FreeIPA-users wrote:

On 02/15/2018 09:29 AM, Florence Blanc-Renaud wrote:

On 02/15/2018 02:40 PM, Bret Wortman via FreeIPA-users wrote:
On 02/15/2018 07:09 AM, Florence Blanc-Renaud via FreeIPA-users 
wrote:

On 02/15/2018 11:47 AM, Bret Wortman via FreeIPA-users wrote:



On 02/15/2018 04:50 AM, Florence Blanc-Renaud wrote:
On 02/15/2018 10:08 AM, Florence Blanc-Renaud via 
FreeIPA-users wrote:

On 02/14/2018 05:58 PM, Bret Wortman wrote:

On 02/14/2018 10:22 AM, Florence Blanc-Renaud wrote:

On 02/14/2018 12:52 PM, Bret Wortman via FreeIPA-users wrote:

I did figure out that I can use

# ldapsearch -D 'directory manager' -W -E pr=2 -b 
idnsname=damascusgrp.com,cn=dns,dc=damascusgrp,dc=com


to list out all the entries, but the format isn't what I'm 
expecting.


What I'm actually trying to do is move our whole 
infrastructure from one set of old & busted servers to 
some shiny new VMs. We'd like to extract the data and 
start fresh, as our replication agreements just don't seem 
to be working as expected. Changes to one don't always 
make it to the other and vice versa. While I'd love to dig 
in and solve that, it's easier right now to try to extract 
the data and reload it into a new server, build new 
replicas, then unbind & re-bind every client to the new 
server using ansible since we also lost our internal CA in 
the process.


So while our current configuration is a mess, we can't 
afford to lose all the host/user/dns/hbac data in our 
servers. Thus, I've been capturing the output to text 
using various ipa *-find commands and have parsers to turn 
those back into new entries on the fresh hosts. DNS is the 
only thing that's holding me up.



Bret


On 02/14/2018 06:33 AM, Bret Wortman wrote:


Also, this doesn't solve the fact that the Web UI always 
produces an error dialog whenever accessing our primary 
zone.



On 02/13/2018 02:19 PM, Natxo Asenjo via FreeIPA-users 
wrote:



On Tue, Feb 13, 2018 at 8:13 PM, Natxo Asenjo 
> 
wrote:



    the canonical way to do this is using ldap paging, with
    ldapsearch  you could try using the -E pr= 
parameter, where
     could be 1000 for instance. That way you know 
you are always

    under the limit imposed by the server.


if you use -E pr=1000/noprompt, it will not prompt to 
continue, nicer for scripts obviously.


--
Groeten,
natxo


___
FreeIPA-users mailing list 
--freeipa-users@lists.fedorahosted.org
To unsubscribe send an email 
tofreeipa-users-le...@lists.fedorahosted.org






___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org



Hi Bret,

the search limits can be set at multiple levels:
- for the whole 389-ds server
nsslapd-sizelimit (in cn=config)
nsslapd-lookthroughlimit (in cn=config,cn=ldbm 
database,cn=plugins,cn=config)


- for operations performed through ipa * commands (or the 
webGUI):

ipaSearchRecordsLimit (in cn=ipaConfig,cn=etc,$BASEDN)

- for each user:
nssizelimit and nsLookThroughLimit attributes (in 
uid=$USER,cn=users,cn=accounts,$BASEDN)


You are probably hitting one of these limits in your ipa 
*-find command.


HTH,
Flo



So I found almost all of these:

# ldapsearch -D 'cn=directory manager' -W -b 'cn=config' 
cn=config | grep nsslapd-sizelimit

nsslapd-sizelimit: 2000

# ldapsearch -D 'cn=directory manager' -W -b 
'cn=config,cn=ldbm database,cn=plugins,cn=config' | grep 
lookthroughlimit

nsslapd-lookthroughlimit: 10

# ldapsearch -D 'cn=directory manager' -W -b 
'cn=ipaConfig,cn=etc,dc=damascusgrp,dc=com' | grep 
ipaSearchRecordsLimit

ipaSearchRecordsLimit: 9

# ldapsearch -D 'cn=directory manager' -W -b 
'uid=admin,cn=users,cn=accounts,dc=damascusgrp,dc=com' | 
grep -i limit

(returns data but nothing matches)


Hi,

nsSizeLimit and nsLookThroughLimit are operational 
attributes, meaning that a standard ldapsearch will not 
return them. You need either to specifically request them by 
providing them in the attributes list:


$ ldapsearch -D 'cn=directory manager' -W -b $BASE 
nssizelimit nslookthroughlimit


or you can also specify + instead of the attributes in order 
to get all operational attributes:

$ ldapsearch -D 'cn=directory manager' -W -b $BASE +

HTH,
Flo

The first doesn't seem to be something I can change. It's 
stuck at 2000, but since my issue occurs at 5000, I'm not 
worried about it. I believe that I'm missing something in 
the fourth search that might point me toward the attributes 
you mentioned but I'm not sure where.




The 5000 limit rings a bell to me. It is 

[Freeipa-users] Re: Fixing limit on DNS searches

[Bret Wortman via FreeIPA-users]

On 02/16/2018 11:54 AM, Florence Blanc-Renaud wrote:

On 02/15/2018 06:42 PM, Bret Wortman via FreeIPA-users wrote:

On 02/15/2018 12:27 PM, Florence Blanc-Renaud wrote:

On 02/15/2018 05:01 PM, Bret Wortman via FreeIPA-users wrote:

On 02/15/2018 09:29 AM, Florence Blanc-Renaud wrote:

On 02/15/2018 02:40 PM, Bret Wortman via FreeIPA-users wrote:
On 02/15/2018 07:09 AM, Florence Blanc-Renaud via FreeIPA-users 
wrote:

On 02/15/2018 11:47 AM, Bret Wortman via FreeIPA-users wrote:



On 02/15/2018 04:50 AM, Florence Blanc-Renaud wrote:
On 02/15/2018 10:08 AM, Florence Blanc-Renaud via 
FreeIPA-users wrote:

On 02/14/2018 05:58 PM, Bret Wortman wrote:

On 02/14/2018 10:22 AM, Florence Blanc-Renaud wrote:

On 02/14/2018 12:52 PM, Bret Wortman via FreeIPA-users wrote:

I did figure out that I can use

# ldapsearch -D 'directory manager' -W -E pr=2 -b 
idnsname=damascusgrp.com,cn=dns,dc=damascusgrp,dc=com


to list out all the entries, but the format isn't what I'm 
expecting.


What I'm actually trying to do is move our whole 
infrastructure from one set of old & busted servers to 
some shiny new VMs. We'd like to extract the data and 
start fresh, as our replication agreements just don't seem 
to be working as expected. Changes to one don't always 
make it to the other and vice versa. While I'd love to dig 
in and solve that, it's easier right now to try to extract 
the data and reload it into a new server, build new 
replicas, then unbind & re-bind every client to the new 
server using ansible since we also lost our internal CA in 
the process.


So while our current configuration is a mess, we can't 
afford to lose all the host/user/dns/hbac data in our 
servers. Thus, I've been capturing the output to text 
using various ipa *-find commands and have parsers to turn 
those back into new entries on the fresh hosts. DNS is the 
only thing that's holding me up.



Bret


On 02/14/2018 06:33 AM, Bret Wortman wrote:


Also, this doesn't solve the fact that the Web UI always 
produces an error dialog whenever accessing our primary 
zone.



On 02/13/2018 02:19 PM, Natxo Asenjo via FreeIPA-users 
wrote:



On Tue, Feb 13, 2018 at 8:13 PM, Natxo Asenjo 
> 
wrote:



    the canonical way to do this is using ldap paging, with
    ldapsearch  you could try using the -E pr= 
parameter, where
     could be 1000 for instance. That way you know 
you are always

    under the limit imposed by the server.


if you use -E pr=1000/noprompt, it will not prompt to 
continue, nicer for scripts obviously.


--
Groeten,
natxo


___
FreeIPA-users mailing list 
--freeipa-users@lists.fedorahosted.org
To unsubscribe send an email 
tofreeipa-users-le...@lists.fedorahosted.org






___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org



Hi Bret,

the search limits can be set at multiple levels:
- for the whole 389-ds server
nsslapd-sizelimit (in cn=config)
nsslapd-lookthroughlimit (in cn=config,cn=ldbm 
database,cn=plugins,cn=config)


- for operations performed through ipa * commands (or the 
webGUI):

ipaSearchRecordsLimit (in cn=ipaConfig,cn=etc,$BASEDN)

- for each user:
nssizelimit and nsLookThroughLimit attributes (in 
uid=$USER,cn=users,cn=accounts,$BASEDN)


You are probably hitting one of these limits in your ipa 
*-find command.


HTH,
Flo



So I found almost all of these:

# ldapsearch -D 'cn=directory manager' -W -b 'cn=config' 
cn=config | grep nsslapd-sizelimit

nsslapd-sizelimit: 2000

# ldapsearch -D 'cn=directory manager' -W -b 
'cn=config,cn=ldbm database,cn=plugins,cn=config' | grep 
lookthroughlimit

nsslapd-lookthroughlimit: 10

# ldapsearch -D 'cn=directory manager' -W -b 
'cn=ipaConfig,cn=etc,dc=damascusgrp,dc=com' | grep 
ipaSearchRecordsLimit

ipaSearchRecordsLimit: 9

# ldapsearch -D 'cn=directory manager' -W -b 
'uid=admin,cn=users,cn=accounts,dc=damascusgrp,dc=com' | 
grep -i limit

(returns data but nothing matches)


Hi,

nsSizeLimit and nsLookThroughLimit are operational 
attributes, meaning that a standard ldapsearch will not 
return them. You need either to specifically request them by 
providing them in the attributes list:


$ ldapsearch -D 'cn=directory manager' -W -b $BASE 
nssizelimit nslookthroughlimit


or you can also specify + instead of the attributes in order 
to get all operational attributes:

$ ldapsearch -D 'cn=directory manager' -W -b $BASE +

HTH,
Flo

The first doesn't seem to be something I can change. It's 
stuck at 2000, but since my issue occurs at 5000, I'm not 
worried about it. I believe that I'm missing something in 
the fourth search that might point me toward the attributes 
you mentioned but I'm not sure where.




The 5000 limit rings a bell to me. It is the anonymous size 
limit. Can you check:
$ ldapsearch -D