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

*
*
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret


On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce <s...@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-us...@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.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to