[Freeipa-users] Exporting data?

[Petr Spacek]

On 5.9.2013 16:49, Bret Wortman wrote:
> That worked for one out of 24 zones. Dig gave the same error on the rest:
>
> # dig +onesoa -t AXFR foo.net
>
> ; <<>> DiG 99.3-rl.156.01-P1-RedHat-9.9.3-3.P1.fc18 <<>> +onesoa -t AXFR
> foo.net
> ;; global options: +cmd
> ; Transfer failed.
> #
>
> /var/log/messages errors at the same time with:
>
> named[925]: LDAP error: Size limit exceeded
> named[925]: connection to the LDAP server was lost
> named[925]: successfully reconnected to LDAP server
>
> I think my master has, to stick with technical terminology, "completely
> lost the plot". And I'm equally certain it's because of something I did to
> it....

Do you use Kerberos authentication for connection from named to LDAP? Did you 
change connection settings/credentials after installation? (in /etc/named.conf?)

I guess that you need to disable size limits for the account used for 
connection between LDAP and named.

Each object in LDAP has operational attributes nsIdleTimeout, 
nsLookThroughLimit, nsSizeLimit and nsTimeLimit. All of them should be set to 
"-1".

Use your favorite LDAP browser to check the values.

You can use attached LDIF as inspiration if you need to change values. Don't 
forget to change service (DNS) and host name 
(your_name_server_name.example.com), REALM NAME (EXAMPLE.COM) and domain name 
(example.com) before you try to import the LDIF.

Just for the case, normal user accounts are stored under 
cn=users,cn=accounts,dc=example,dc=com but service accounts are stored under 
cn=services,cn=accounts,dc=example,dc=com.

Petr^2 Spacek

> On Thu, Sep 5, 2013 at 7:48 AM, Bret Wortman
> <bret.wortman at damascusgrp.com>wrote:
>
>> D'Oh! Thanks, Petr.
>>
>>
>> *
>> *
>> *Bret Wortman*
>>
>> http://damascusgrp.com/
>> http://about.me/wortmanbret
>>
>>
>> On Thu, Sep 5, 2013 at 2:33 AM, Petr Spacek <pspacek at redhat.com> wrote:
>>
>>> On 4.9.2013 20:23, Bret Wortman wrote:
>>>
>>>> ...and I tried exporting the DNS data but ended up with a bunch of files
>>>> that looked liket his:
>>>>
>>>> # cat foo.net.db
>>>>
>>>> ; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.**3-3.P1.fc18 <<>> +onesoa -t
>>>> AXFR
>>>> foo.net
>>>> ;; global options: +cmd
>>>> ; Transfer failed.
>>>> #
>>>>
>>>> The logs showed:
>>>>
>>>> <timestamp> ipamaster named[31633]: client 1.2.3.4#39992 (foo.net) :
>>>> zone
>>>> transfer 'foo.net/AXFR/IN' denied
>>>>
>>>
>>> You have to add IP '1.2.3.4' to the allow-transfer Address List Match.
>>>
>>> $ ipa dnszone-mod --allow-transfer='localhost; 1.2.3.4;'
>>>
>>> See
>>> http://www.zytrax.com/books/**dns/ch7/address_match_list.**html<http://www.zytrax.com/books/dns/ch7/address_match_list.html>
>>> for further details.
>>>
>>> Petr^2 Spacek
>>>
>>>
>>>   On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce <simo at redhat.com> wrote:
>>>>
>>>>   On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote:
>>>>>
>>>>>> On 09/04/2013 09:26 AM, Petr Spacek wrote:
>>>>>>
>>>>>>> On 4.9.2013 15:04, Bret Wortman wrote:
>>>>>>>
>>>>>>>> What's the right venue for making a suggestion? In particular, I'd
>>>>>>>> like to
>>>>>>>> toss out there that it would be really nice to be able to export, at
>>>>>>>> a
>>>>>>>> minimum, DNS and user data from IPA in the form of a zone file and a
>>>>>>>> passwd/shadow file pair.
>>>>>>>>
>>>>>>>> I realize there might be security implications to the latter, and
>>>>>>>> masking
>>>>>>>> out passwords might be advisiable. And there's no easy way,
>>>>>>>> necessarily, to
>>>>>>>> get out sudo information. But having DNS and user details would at
>>>>>>>>
>>>>>>> least
>>>>>
>>>>>> permit a sysadmin having major issues (like I have been for the past
>>>>>>>>
>>>>>>> two
>>>>>
>>>>>> weeks) to get up and running in some form, using puppet or some other
>>>>>>>> tool
>>>>>>>> to distribute flat files with named running against a static zone
>>>>>>>> file, or
>>>>>>>> even to migrate off IPA if absolutely necessary.
>>>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> for DNS you can use normal zone transfer. Just configure IPA zone to
>>>>>>> allow zone transfer to an IP address (localhost means 'localy to IPA
>>>>>>> server') and use standard DNS tools, e.g. dig:
>>>>>>>
>>>>>>> $ ipa dnszone-mod example.com --allow-transfer='localhost;'
>>>>>>> $ dig +onesoa -t AXFR example.com > /root/example.com.db
>>>>>>>
>>>>>>> That is all you need for DNS, you have the standard zone file.
>>>>>>>
>>>>>>>
>>>>>>> I believe that you can use SSSD (with enumeration enabled) to run
>>>>>>> "getent passwd > /root/passwd.bck". I have no idea how it works with
>>>>>>> shadow map/password. Try to ask sssd-users at lists.fedorahosted.**org<sssd-users at lists.fedorahosted.org>
>>>>>>> .
>>>>>>>
>>>>>>>   And to add to it:
>>>>>> IPA does not keep password in clear or the hashes that are used in
>>>>>> passwd and shadow files for security reasons so it can't generate these
>>>>>> files as you suggest.
>>>>>>
>>>>>
>>>>> We do have hashes, the default is SHA256, it is stored in userPassword
>>>>> and is used to validate LDAP binds, however we never let it out of LDAP,
>>>>> neither SSSD not the integrate NIS server expose the password hash to
>>>>> clients. You need Directory Manager privileges to read it.


-- 
Petr^2 Spacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dns-principal.ldif
Type: text/x-ldif
Size: 199 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130905/73853b51/attachment.bin>