Re: [Freeipa-users] Replica cannot be reinitialized after upgrade
Hi Goran Exact same issue here with the same troubleshooting steps taken(I've tried to reinitialize the replicas with success msg) - no luck so far. I've additionally have run ipa_check_consistency script: FreeIPA servers:ipa1 ipa2 ipa3STATE === Active Users373737OK Stage Users 0 0 0 OK Preserved Users 0 0 0 OK User Groups 101010OK Hosts 696969OK Host Groups 7 7 7 OK HBAC Rules 111111OK SUDO Rules 1 1 1 OK DNS Zones 8 8 8 OK LDAP Conflicts YES YES YES FAIL Ghost Replicas NONONOOK Anonymous BIND YES YES YES OK Replication Status ipa2 18 ipa1 0ipa1 0 ipa3 0 === Besides of this the ipa master named-pkcs is sometimes crashing and ipa fails to start. I've rolled a backup from 1week ago and it's starting but I don't know how long it will last. IPA team please help. # ipa --version VERSION: 4.4.0, API_VERSION: 2.213 -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC On Thu, May 11, 2017 at 6:53 PM, Goran Marik <gor...@ecobee.com> wrote: > Hi, > > After an upgrade to Centos 7.3.1611 with “yum update", we started seeing > the following messages in the logs: > “”” > May 9 21:58:28 inf01 ns-slapd[4323]: [09/May/2017:21:58:28.519724479 > +] NSMMReplicationPlugin - changelog program - agmt="cn=cloneAgreement1- > inf02.dev.ecobee.com-pki-tomcat" (inf02:389): CSN 576b34e8000a050f > not found, we aren't as up to date, or we purged > May 9 21:58:28 inf01 ns-slapd[4323]: [09/May/2017:21:58:28.550459233 > +] NSMMReplicationPlugin - agmt="cn=cloneAgreement1- > inf02.dev.ecobee.com-pki-tomcat" (inf02:389): Data required to update > replica has been purged from the changelog. The replica must be > reinitialized. > May 9 21:58:32 inf01 ns-slapd[4323]: [09/May/2017:21:58:32.588245476 > +] agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" > (inf02:389) - Can't locate CSN 576b34e8000a050f in the changelog (DB > rc=-30988). If replication stops, the consumer may need to be reinitialized. > May 9 21:58:32 inf01 ns-slapd[4323]: [09/May/2017:21:58:32.611400689 > +] NSMMReplicationPlugin - changelog program - agmt="cn=cloneAgreement1- > inf02.dev.ecobee.com-pki-tomcat" (inf02:389): CSN 576b34e8000a050f > not found, we aren't as up to date, or we purged > May 9 21:58:32 inf01 ns-slapd[4323]: [09/May/2017:21:58:32.642226385 > +] NSMMReplicationPlugin - agmt="cn=cloneAgreement1- > inf02.dev.ecobee.com-pki-tomcat" (inf02:389): Data required to update > replica has been purged from the changelog. The replica must be > reinitialized. > “”” > > The log messages are pretty frequently, every few seconds, and report few > different CSN numbers that cannot be located. > > This happens only on one replica out of 4. We’ve tried "ipa-replica-manage > re-initialize —from” and “ipa-csreplica-manage re-initialize —from” several > times, but while both commands report success, the log messages continue to > happen. The server was rebooted and “systemctl restart ipa” was done few > times as well. > > The replica seems to be working fine despite the errors, but I’m worried > that the logs indicate underlaying problem we are not fully detecting. I > would like to understand better what is triggering this behaviour and how > to fix it, and if someone else saw them after a recent upgrades. > > The software versions are 389-ds-base-1.3.5.10-20.el7_3.x86_64 and > ipa-server-4.4.0-14.el7.centos.7.x86_64 > > Thanks, > Goran > > -- > Goran Marik > Senior Systems Developer > > ecobee > 250 University Ave, Suite 400 > Toronto, ON M5H 3E5 > > > > -- > 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] Jenkins integration?
Just tried with LDAPs over jxplorer and jenkins. Unfortunately it's not working. The master jenkins release supports ipa auto detection. https://gerrit-review.googlesource.com/#/c/94925/ I will give it a try. On Fri, Mar 24, 2017 at 2:06 PM, Alexander Bokovoy <aboko...@redhat.com> wrote: > On pe, 24 maalis 2017, Maciej Drobniuch wrote: > >> I see now what you mean. >> >> The SSHA decoding is handled on the client side by using acegi not on the >> ldap server side... >> >> Am I inline with this? >> > No, you are not. There are multiple LDAP authentication providers > (authenticators) in Acegi Security framework. When using > org.acegisecurity.providers.ldap.authenticator.BindAuthenticator, it > does actual LDAP bind against LDAP server and never checks the password > by itself. Successful LDAP bind is considered a successful password > check. Jenkins extends BindAuthenticator code with a very small wrapper > to allow better error messaging. It is called BindAuthenticator2. But it > doesn't change the fact that it uses LDAP bind. > > I believe it is actually a default configuration in Jenkins ldap auth > plugin. However, LDAP servers may require that LDAP bind is executed > over a secure channel because your password is passed to LDAP server in > clear text form. Such secure channel has to be established either with > LDAP StartTLS (preferred) or by using LDAPS protocol. > > I guess what you have is a situation where both LDAP StartTLS and LDAPS > aren't in use. > > > >> I'm logging in with cn=Directory Manager (no issues) but it fails with the >> user dn(jxplorer) >> >> I'll try figure this out with the jenkins mailing list. >> >> Thanks Alex. >> >> >> On Fri, Mar 24, 2017 at 11:57 AM, Alexander Bokovoy <aboko...@redhat.com> >> wrote: >> >> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >>> >>> Hi Alex, >>>> >>>> Even while using LDAP a browser (jxplorer) I can not login with the >>>> following user DN >>>> uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com >>>> >>>> javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid >>>> Credentials] >>>> >>>> Only the Directory Manager cn and pwd works. >>>> Any ideas what am I doing wrong? >>>> >>>> LDAP error code 49 means you actually trying to authenticate using LDAP >>> bind but your credentials aren't correct. >>> >>> I don't understand how jxplorer use is relevant to Jenkins plugin setup, >>> though. jxplorer does not use the same Java stack (acegi security) as >>> Jenkins. >>> >>> I cannot test jxplorer on Fedora 25 machine because it fails to launch >>> with Wayland. >>> >>> >>> >>> Thanks! >>>> >>>> On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy < >>>> aboko...@redhat.com> >>>> wrote: >>>> >>>> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >>>> >>>>> >>>>> Hi All, >>>>> >>>>>> >>>>>> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >>>>>> >>>>>> The thing with the Freeipa LDAP server is: >>>>>> * Only Directory Manager can read userPassword field (not sure yet how >>>>>> to >>>>>> create a sysaccount which can read the field. ldifs are welcome ;) >>>>>> >>>>>> This is absolutely not needed. You should configure Jenkins to perform >>>>>> >>>>> LDAP bind with user password against IPA LDAP server, that's all. This >>>>> is supported by acegi security framework that Jenkins LDAP plugin is >>>>> using. For example, >>>>> https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai >>>>> n/resources/hudson/security/LDAPBindSecurityRealm.groovy >>>>> actually uses >>>>> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 >>>>> which >>>>> does support normal LDAP bind. >>>>> >>>>> I think it is, in fact, a default setup for Jenkins LDAP auth plugin, >>>>> so >>>>> you actually needed to do something to disable this path. >>>>> >>>>> >>>>> * The userPassword field contains the password in salted SHA (SSHA) >>>>> format. >>>>> >>>>> From what I've observe
Re: [Freeipa-users] Jenkins integration?
I see now what you mean. The SSHA decoding is handled on the client side by using acegi not on the ldap server side... Am I inline with this? I'm logging in with cn=Directory Manager (no issues) but it fails with the user dn(jxplorer) I'll try figure this out with the jenkins mailing list. Thanks Alex. On Fri, Mar 24, 2017 at 11:57 AM, Alexander Bokovoy <aboko...@redhat.com> wrote: > On pe, 24 maalis 2017, Maciej Drobniuch wrote: > >> Hi Alex, >> >> Even while using LDAP a browser (jxplorer) I can not login with the >> following user DN >> uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com >> >> javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid >> Credentials] >> >> Only the Directory Manager cn and pwd works. >> Any ideas what am I doing wrong? >> > LDAP error code 49 means you actually trying to authenticate using LDAP > bind but your credentials aren't correct. > > I don't understand how jxplorer use is relevant to Jenkins plugin setup, > though. jxplorer does not use the same Java stack (acegi security) as > Jenkins. > > I cannot test jxplorer on Fedora 25 machine because it fails to launch > with Wayland. > > > >> Thanks! >> >> On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy <aboko...@redhat.com> >> wrote: >> >> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >>> >>> Hi All, >>>> >>>> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >>>> >>>> The thing with the Freeipa LDAP server is: >>>> * Only Directory Manager can read userPassword field (not sure yet how >>>> to >>>> create a sysaccount which can read the field. ldifs are welcome ;) >>>> >>>> This is absolutely not needed. You should configure Jenkins to perform >>> LDAP bind with user password against IPA LDAP server, that's all. This >>> is supported by acegi security framework that Jenkins LDAP plugin is >>> using. For example, >>> https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai >>> n/resources/hudson/security/LDAPBindSecurityRealm.groovy >>> actually uses >>> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 which >>> does support normal LDAP bind. >>> >>> I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so >>> you actually needed to do something to disable this path. >>> >>> >>> * The userPassword field contains the password in salted SHA (SSHA) >>> format. >>> >>>> From what I've observed the standard LDAP auth functions do not do the >>>> SSHA >>>> or any other type of calculations. The password is compared to the plain >>>> text that's usually(in a typical OpenLDAP server) stored in the >>>> userPassword field(correct me if I'm wrong) >>>> * I've managed to integrate CACTI with freeipa by base64 decoding the >>>> userPassword field then calculating the salted hash and comparing to the >>>> userPassword field. (php code modification was required). >>>> * I think the only way is to modify the jenkins LDAP plugin (?). >>>> >>>> The problem: >>>> * I don't want to use sssd PAM because we have OTP enabled and that >>>> would >>>> annoy users(?) additionally it's causing some unidentified build issues >>>> BTW> Can I disable OTP per server? >>>> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >>>> connected to the principal(no control over them yet) >>>> * I want simple LDAP auth ;-) >>>> >>>> So use simple LDAP bind. >>> >>> >>> >>> Ideas & suggestions are welcome! >>>> >>>> M. >>>> >>>> On Sat, Feb 11, 2017 at 4:28 PM, Michael Ströder <mich...@stroeder.com> >>>> wrote: >>>> >>>> Alexander Bokovoy wrote: >>>> >>>>> > On la, 11 helmi 2017, Michael Ströder wrote: >>>>> >> Alexander Bokovoy wrote: >>>>> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>>>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>>>> >>>>> On la, 11 helmi 2017, Michael Ströder wrote: >>>>> >>>>>> >>>>> >>>>>> (Personally I'd avoid going through PAM.) >>>>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >&
Re: [Freeipa-users] Jenkins integration?
Hi Alex, Even while using LDAP a browser (jxplorer) I can not login with the following user DN uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials] Only the Directory Manager cn and pwd works. Any ideas what am I doing wrong? Thanks! On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy <aboko...@redhat.com> wrote: > On pe, 24 maalis 2017, Maciej Drobniuch wrote: > >> Hi All, >> >> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >> >> The thing with the Freeipa LDAP server is: >> * Only Directory Manager can read userPassword field (not sure yet how to >> create a sysaccount which can read the field. ldifs are welcome ;) >> > This is absolutely not needed. You should configure Jenkins to perform > LDAP bind with user password against IPA LDAP server, that's all. This > is supported by acegi security framework that Jenkins LDAP plugin is > using. For example, > https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai > n/resources/hudson/security/LDAPBindSecurityRealm.groovy > actually uses > org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 which > does support normal LDAP bind. > > I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so > you actually needed to do something to disable this path. > > > * The userPassword field contains the password in salted SHA (SSHA) format. >> From what I've observed the standard LDAP auth functions do not do the >> SSHA >> or any other type of calculations. The password is compared to the plain >> text that's usually(in a typical OpenLDAP server) stored in the >> userPassword field(correct me if I'm wrong) >> * I've managed to integrate CACTI with freeipa by base64 decoding the >> userPassword field then calculating the salted hash and comparing to the >> userPassword field. (php code modification was required). >> * I think the only way is to modify the jenkins LDAP plugin (?). >> >> The problem: >> * I don't want to use sssd PAM because we have OTP enabled and that would >> annoy users(?) additionally it's causing some unidentified build issues >> BTW> Can I disable OTP per server? >> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >> connected to the principal(no control over them yet) >> * I want simple LDAP auth ;-) >> > So use simple LDAP bind. > > > >> Ideas & suggestions are welcome! >> >> M. >> >> On Sat, Feb 11, 2017 at 4:28 PM, Michael Ströder <mich...@stroeder.com> >> wrote: >> >> Alexander Bokovoy wrote: >>> > On la, 11 helmi 2017, Michael Ströder wrote: >>> >> Alexander Bokovoy wrote: >>> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>> >>>>> On la, 11 helmi 2017, Michael Ströder wrote: >>> >>>>>> >>> >>>>>> (Personally I'd avoid going through PAM.) >>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >>> involved >>> >>>>> you get also authentication for trusted users from Active Directory >>> >>>>> realms. You don't get that with generic LDAP way. Also, you'd be >>> more >>> >>>>> efficient in terms of utilising LDAP connections. >>> >>>>> >>> >>>> >>> >>>> I would prefer if the users are not allowed to login into a >>> >>>> shell on the Jenkins server. Surely this restriction can be >>> >>>> implemented with pam as well. >>> >>> >>> >>> Yes, you can use HBAC rules to prevent them from access to the host. >>> >> >>> >> But this introduces a hard dependency on host system administration >>> which I personally >>> >> always try to avoid. >>> >> >>> >> As said: Your mileage may vary. >>> > >>> > So we are talking about FreeIPA and a system enrolled to FreeIPA. This >>> > system is already managed in FreeIPA. >>> >>> Please don't get me wrong. Of course I assume that the original poster >>> wants to integrate >>> Jenkins with FreeIPA and make use of users and their group membership >>> already maintained >>> therein. >>> >>> Let's further assume that the service (here Jenkins) might be operated by >>> another team >>> than the system - not so
Re: [Freeipa-users] Jenkins integration?
Hi All, I'm trying to integrate Freeipa with jenkins and ldap auth plugin. The thing with the Freeipa LDAP server is: * Only Directory Manager can read userPassword field (not sure yet how to create a sysaccount which can read the field. ldifs are welcome ;) * The userPassword field contains the password in salted SHA (SSHA) format. >From what I've observed the standard LDAP auth functions do not do the SSHA or any other type of calculations. The password is compared to the plain text that's usually(in a typical OpenLDAP server) stored in the userPassword field(correct me if I'm wrong) * I've managed to integrate CACTI with freeipa by base64 decoding the userPassword field then calculating the salted hash and comparing to the userPassword field. (php code modification was required). * I think the only way is to modify the jenkins LDAP plugin (?). The problem: * I don't want to use sssd PAM because we have OTP enabled and that would annoy users(?) additionally it's causing some unidentified build issues BTW> Can I disable OTP per server? * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not connected to the principal(no control over them yet) * I want simple LDAP auth ;-) Ideas & suggestions are welcome! M. On Sat, Feb 11, 2017 at 4:28 PM, Michael Ströder <mich...@stroeder.com> wrote: > Alexander Bokovoy wrote: > > On la, 11 helmi 2017, Michael Ströder wrote: > >> Alexander Bokovoy wrote: > >>> On la, 11 helmi 2017, Harald Dunkel wrote: > >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: > >>>>> On la, 11 helmi 2017, Michael Ströder wrote: > >>>>>> > >>>>>> (Personally I'd avoid going through PAM.) > >>>>> Any specific reason for not using pam_sss? Remember, with SSSD > involved > >>>>> you get also authentication for trusted users from Active Directory > >>>>> realms. You don't get that with generic LDAP way. Also, you'd be more > >>>>> efficient in terms of utilising LDAP connections. > >>>>> > >>>> > >>>> I would prefer if the users are not allowed to login into a > >>>> shell on the Jenkins server. Surely this restriction can be > >>>> implemented with pam as well. > >>> > >>> Yes, you can use HBAC rules to prevent them from access to the host. > >> > >> But this introduces a hard dependency on host system administration > which I personally > >> always try to avoid. > >> > >> As said: Your mileage may vary. > > > > So we are talking about FreeIPA and a system enrolled to FreeIPA. This > > system is already managed in FreeIPA. > > Please don't get me wrong. Of course I assume that the original poster > wants to integrate > Jenkins with FreeIPA and make use of users and their group membership > already maintained > therein. > > Let's further assume that the service (here Jenkins) might be operated by > another team > than the system - not so unusual case at my customers' sites - relying on > defining HBAC > rules for the system's sssd might not be feasible. > > > Your mileage may vary, indeed, but I'd rather re-use what is available > > to you than implement a parallel infrastructure, including reliability > > aspects. > > Of course we both agree on the benefits of using what's already available. > > > Anyway, I think we are distancing away from the original topic. > > Especially since we both can only make rough assumptions about > requirements and > operational constraints of the original poster. > > 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 > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -- 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] 2FA and AllowNTHash
Hi Brian
Thank You for your answer.
It started working, not sure yet why it did not work. I need to do some
extensive testing.
So, I've actually followed the blogposts you've mentioned to setup
ipanthash + freeradius.
Maybe I'll paraphrase the question.
It would suffice if I could tell IPA to use pass+otp only instead of both
(Password+ pass+otp) for particular hosts.
So for example users from hosts X can login with OTP only.
Thanks for help!
On Tue, Jan 3, 2017 at 7:02 PM, Brian Candler <b.cand...@pobox.com> wrote:
> On 03/01/2017 15:28, Maciej Drobniuch wrote:
>
>> We have a topo with 3x IPA servers + freeradius.
>>
>> Freeradius is being used to do mschap with wifi APs. Freeradius connects
>> over ldap to IPA.
>>
>> In order to do the challange-response thing, freeipa has AllowNTHash
>> enabled.
>>
>> So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth.
>>
>> In the moment I disallow Password auth for a user and enable OTP the wifi
>> auth stopps working, but the hash clearly stays in ldap.
>>
> How are you actually authenticating the user? Are you just reading the
> ipaNTHash out of the LDAP database and letting FreeRADIUS check it? Then
> AFAICS it shouldn't make any different whether OTP is enabled or not. Can
> you show more of your RADIUS config, and the debug output from the part
> which authenticates the user?
>
> I don't use OTP myself, but I wouldn't expect the ipaNTHash to change
> depending on whether OTP is enabled or not (and you're saying the hash
> stays put).
>
> I have what sounds like a similar setup to yours, using FreeRADIUS 3.0.12
> talking to FreeIPA 4.4.0, using a service user which has permissions to
> read out the ipaNTHash directly, based on this blog post:
> http://firstyear.id.au/blog/html/2015/07/06/FreeIPA:_Giving_
> permissions_to_service_accounts..html
>
> ldap config:
>
> base_dn = 'cn=users,cn=accounts,dc=ipa,dc=example,dc=com'
>
> sasl {
> mech = 'GSSAPI'
> realm = 'IPA.EXAMPLE.COM'
> }
>
> update {
> control:NT-Password := 'ipaNTHash'
> control:Tmp-String-9:= 'krbPasswordExpiration'
> }
>
> user {
> base_dn = "${..base_dn}"
> filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
> scope = "one"
> }
>
> group {
> membership_attribute = 'memberOf'
> name_attributes = 'cn'
>
> cacheable_dn = 'yes'
> cacheable_name = 'no'
> }
>
> default and inner-tunnel authentication is then just:
>
> authenticate {
> Auth-Type PAP {
> pap
> }
>
> Auth-Type MS-CHAP {
> mschap
> }
>
> eap
> }
>
> Also you need to put the service user's keytab somewhere, and set a couple
> of environment variables when it starts, if you want to use Kerberos to
> protect the LDAP connection. Using systemd override:
>
> [Unit]
> Requires=dirsrv.target
> After=dirsrv.target
>
> [Service]
> Environment=KRB5_CLIENT_KTNAME=/etc/radiusd.keytab
> Environment=KRB5CCNAME=MEMORY:
> Restart=always
> RestartSec=5
>
> (Otherwise you can bind with a specific dn and password, but then you also
> need to sort out TLS to secure the LDAP traffic)
>
> There is more magic you can do with the krbPasswordExpiration attribute to
> force the user to do a password change over MSCHAP - but that's now
> straying a long way from what's relevant on a FreeIPA mailing list.
>
> HTH,
>
> Brian.
>
--
Best regards
Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
--
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] LDAP - Load Balancer - SSL cert with SAN
I see.
Generally the SAN thing I mentioned does the job but definitely not in your
case.
A IPA power user is needed here.
On Tue, Jan 3, 2017 at 4:26 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:
> Maciej,
> Thank you for the information. I am not terminating at a load
> balancer. Originally, I was trying to use a Route53 DNS CNAME entry of
> ipa.dev.crosschx.com but we found documentation that says the entry
> should be an A record and not a CNAME. I then created an A record in
> FreeIPA for ipa.dev.crosschx.com and pointed the A record to the IP
> addresses of ipa-master.dev.crosschx.com and ipa-replica.dev.crosschx.com.
>
> I guess using the phrase load balancer may be a poor choice here as I am
> using FreeIPA DNS as a way to load balance the traffic.
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614-741-5475 <(614)%20741-5475>
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Tue, Jan 3, 2017 at 10:14 AM, Maciej Drobniuch <m...@collective-sense.com
> > wrote:
>
>> Hello Mike,
>>
>> I don't know if I'm aligned with your problem, but generally I was facing
>> a SAN cert issue too.
>>
>> Not sure if you're terminating SSL/TLS on the load balancer or not?
>>
>> Usually I do SAN certs in IPA via GUI/IdM.
>> I am adding a service and hosts assigned to that service.
>>
>> Every host has an additional https service.
>>
>> Then I am simply pasting the SAN csr into the host that owns the main
>> service and this creates a signed SAN cert that you can upload later to
>> your LB.
>>
>> In simple words the service is assigned to all hosts but those hosts have
>> also a service added(this is a hack).
>>
>> Hope that makes sense and helps solving your problem.
>>
>> BR
>>
>> On Thu, Dec 29, 2016 at 10:48 PM, Michael Plemmons <
>> michael.plemm...@crosschx.com> wrote:
>>
>>> I am trying to get FreeIPA LDAP to work when behind a load balancer and
>>> using SSL and I do not understand how I am supposed to get the server to
>>> use a certificate I created that has a SAN created.
>>>
>>> FreeIPA 4.4.0 on CentOS 7
>>>
>>> Here is what I have:
>>> ipa-master.dev.crosschx.com - master
>>> ipa-replica.dev.crosschx.com - replica
>>> ipa.dev.crosschx.com - load balancer DNS name which point to the master
>>> and replica servers
>>>
>>> Here is what I have done.
>>> ipa host-add ipa.dev.crosschx.com --random --force
>>>
>>> ipa service-add --force ldap/ipa.dev.crosschx.com
>>>
>>> ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={
>>> ipa-master.dev.crosschx.com,ipa-replica.dev.crosschx.com}
>>>
>>> ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com
>>> --users=admin
>>>
>>> ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN=
>>> ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com
>>> -K ldap/ipa-master.dev.crosschx.com
>>>
>>>
>>> I can see the certificate is being monitored by IPA when I run
>>> ipa-getcert list but I am lost at the step to have this cert put into the
>>> database so that IPA will properly respond when I try to connect over LDAPS.
>>>
>>> I was testing the connection with the following command and I see the
>>> the ipa-master.dev cert being served.
>>>
>>> openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername
>>> ipa.dev.crosschx.com
>>>
>>> Can you point me to the documentation I need to follow?
>>>
>>> Thank you.
>>>
>>>
>>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
>>> 614-741-5475 <(614)%20741-5475>
>>> mike.plemm...@crosschx.com
>>> www.crosschx.com
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Best regards
>>
>> Maciej Drobniuch
>> Network Security Engineer
>> Collective-Sense,LLC
>>
>
>
--
Best regards
Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
--
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] 2FA and AllowNTHash
Hi All, We have a topo with 3x IPA servers + freeradius. Freeradius is being used to do mschap with wifi APs. Freeradius connects over ldap to IPA. In order to do the challange-response thing, freeipa has AllowNTHash enabled. So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth. In the moment I disallow Password auth for a user and enable OTP the wifi auth stopps working, but the hash clearly stays in ldap. The goal is to stay with password on freeradius but for everything else: kerberos/sssd related use password+code. How can I disable password login for user but still make freeradius work with ldap, so when it asks for users hash it gets one. Freeradius ldap mod snippet: "base_dn = "cn=users,cn=accounts,dc=cs,dc=com"" Thank You -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -- 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] LDAP - Load Balancer - SSL cert with SAN
Hello Mike,
I don't know if I'm aligned with your problem, but generally I was facing a
SAN cert issue too.
Not sure if you're terminating SSL/TLS on the load balancer or not?
Usually I do SAN certs in IPA via GUI/IdM.
I am adding a service and hosts assigned to that service.
Every host has an additional https service.
Then I am simply pasting the SAN csr into the host that owns the main
service and this creates a signed SAN cert that you can upload later to
your LB.
In simple words the service is assigned to all hosts but those hosts have
also a service added(this is a hack).
Hope that makes sense and helps solving your problem.
BR
On Thu, Dec 29, 2016 at 10:48 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:
> I am trying to get FreeIPA LDAP to work when behind a load balancer and
> using SSL and I do not understand how I am supposed to get the server to
> use a certificate I created that has a SAN created.
>
> FreeIPA 4.4.0 on CentOS 7
>
> Here is what I have:
> ipa-master.dev.crosschx.com - master
> ipa-replica.dev.crosschx.com - replica
> ipa.dev.crosschx.com - load balancer DNS name which point to the master
> and replica servers
>
> Here is what I have done.
> ipa host-add ipa.dev.crosschx.com --random --force
>
> ipa service-add --force ldap/ipa.dev.crosschx.com
>
> ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={ipa-master.dev.
> crosschx.com,ipa-replica.dev.crosschx.com}
>
> ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com --users=admin
>
> ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN=
> ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com
> -K ldap/ipa-master.dev.crosschx.com
>
>
> I can see the certificate is being monitored by IPA when I run ipa-getcert
> list but I am lost at the step to have this cert put into the database so
> that IPA will properly respond when I try to connect over LDAPS.
>
> I was testing the connection with the following command and I see the the
> ipa-master.dev cert being served.
>
> openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername
> ipa.dev.crosschx.com
>
> Can you point me to the documentation I need to follow?
>
> Thank you.
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614-741-5475 <(614)%20741-5475>
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> --
> 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
>
--
Best regards
Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
--
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] DNS reverse zone is not managed by this server
Martin,
Your troubleshooting style put me on the right track.
The alternative DNS servers had Ipv6 records that did not resolv
properly.
After deleting those records adding A records (with reverse PTR check) and
adding host works fine. The PTR record is created in the GUI and works fine.
Thank you very much for your time and help with this!
Cheers!
M.
On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch <m...@collective-sense.com>
wrote:
> # dig soa 0.0.10.in-addr.arpa.
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;0.0.10.in-addr.arpa. IN SOA
>
> ;; ANSWER SECTION:
> 0.0.10.in-addr.arpa. 86400 IN SOA freeipa1.cs.int. hostmaster.cs.int.
> 1482653944 3600 900 1209600 3600
>
> ;; AUTHORITY SECTION:
> 0.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
> 0.0.10.in-addr.arpa. 86400 IN NS freeipa2.cs.int.
> 0.0.10.in-addr.arpa. 86400 IN NS krkfreeipa.cs.int.
>
> ;; ADDITIONAL SECTION:
> freeipa1.cs.int. 1200 IN A 10.0.0.200
> freeipa2.cs.int. 1200 IN A 10.0.1.200
> krkfreeipa.cs.int. 1200 IN A 10.0.2.6
>
> ;; Query time: 15 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: wto gru 27 07:33:41 EST 2016
> ;; MSG SIZE rcvd: 333
>
>
> On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti <mba...@redhat.com> wrote:
>
>> I just noticed previously you sent wrong dig, I need
>>
>> dig 0.0.10.in-addr.arpa. SOA instead of the A rtype
>>
>>
>>
>>
>> On 27.12.2016 13:21, Maciej Drobniuch wrote:
>>
>> # python -c 'from dns import resolver; a =
>> resolver.query("0.0.10.in-addr.arpa.",
>> "SOA", "IN"); print a.rrset.name'
>> 0.0.10.in-addr.arpa.
>>
>> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti <mba...@redhat.com> wrote:
>>
>>>
>>>
>>> On 27.12.2016 13:04, Maciej Drobniuch wrote:
>>>
>>> $ dig 0.0.10.in-addr.arpa
>>>
>>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;0.0.10.in-addr.arpa. IN A
>>>
>>> ;; AUTHORITY SECTION:
>>> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
>>> 1482653944 3600 900 1209600 3600
>>>
>>> ;; Query time: 197 msec
>>> ;; SERVER: 10.0.0.200#53(10.0.0.200)
>>> ;; WHEN: Tue Dec 27 13:02:24 CET 2016
>>> ;; MSG SIZE rcvd: 111
>>>
>>>
>>> Hmm, this query doesn't contain ANSWER section, that may be reason why
>>> python-dns failed.
>>>
>>> could you check with:
>>>
>>> python -c 'from dns import resolver; a =
>>> resolver.query("0.0.10.in-addr.arpa.",
>>> "SOA", "IN"); print a.rrset.name'
>>>
>>>
>>>
>>> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mba...@redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>>>>
>>>> Hi Martin!
>>>>
>>>> Thank you for your time!
>>>>
>>>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mba...@redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>>>>>
>>>>> Hi Martin
>>>>>
>>>>> Appreciate your help!
>>>>>
>>>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>>>>>
>>>>>> Hi Martin
>>>>>>
>>>>>> Thank you for reply.
>>>>>>
>>>>>> 1. The dig is returning proper PTR record. I've added it manually to
>>>>>> the zone and it's working.
>>>>>>
>>>>>>
>>&
Re: [Freeipa-users] DNS reverse zone is not managed by this server
# dig soa 0.0.10.in-addr.arpa.
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa. IN SOA
;; ANSWER SECTION:
0.0.10.in-addr.arpa. 86400 IN SOA freeipa1.cs.int. hostmaster.cs.int.
1482653944 3600 900 1209600 3600
;; AUTHORITY SECTION:
0.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
0.0.10.in-addr.arpa. 86400 IN NS freeipa2.cs.int.
0.0.10.in-addr.arpa. 86400 IN NS krkfreeipa.cs.int.
;; ADDITIONAL SECTION:
freeipa1.cs.int. 1200 IN A 10.0.0.200
freeipa2.cs.int. 1200 IN A 10.0.1.200
krkfreeipa.cs.int. 1200 IN A 10.0.2.6
;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: wto gru 27 07:33:41 EST 2016
;; MSG SIZE rcvd: 333
On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti <mba...@redhat.com> wrote:
> I just noticed previously you sent wrong dig, I need
>
> dig 0.0.10.in-addr.arpa. SOA instead of the A rtype
>
>
>
>
> On 27.12.2016 13:21, Maciej Drobniuch wrote:
>
> # python -c 'from dns import resolver; a =
> resolver.query("0.0.10.in-addr.arpa.",
> "SOA", "IN"); print a.rrset.name'
> 0.0.10.in-addr.arpa.
>
> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti <mba...@redhat.com> wrote:
>
>>
>>
>> On 27.12.2016 13:04, Maciej Drobniuch wrote:
>>
>> $ dig 0.0.10.in-addr.arpa
>>
>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;0.0.10.in-addr.arpa. IN A
>>
>> ;; AUTHORITY SECTION:
>> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
>> 1482653944 3600 900 1209600 3600
>>
>> ;; Query time: 197 msec
>> ;; SERVER: 10.0.0.200#53(10.0.0.200)
>> ;; WHEN: Tue Dec 27 13:02:24 CET 2016
>> ;; MSG SIZE rcvd: 111
>>
>>
>> Hmm, this query doesn't contain ANSWER section, that may be reason why
>> python-dns failed.
>>
>> could you check with:
>>
>> python -c 'from dns import resolver; a =
>> resolver.query("0.0.10.in-addr.arpa.",
>> "SOA", "IN"); print a.rrset.name'
>>
>>
>>
>> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mba...@redhat.com> wrote:
>>
>>>
>>>
>>> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>>>
>>> Hi Martin!
>>>
>>> Thank you for your time!
>>>
>>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mba...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>>>>
>>>> Hi Martin
>>>>
>>>> Appreciate your help!
>>>>
>>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>>>>
>>>>> Hi Martin
>>>>>
>>>>> Thank you for reply.
>>>>>
>>>>> 1. The dig is returning proper PTR record. I've added it manually to
>>>>> the zone and it's working.
>>>>>
>>>>>
>>>>> I was asking for SOA and zone name, IMO there is nothing secret about
>>>>> reverse zone name from private address space
>>>>>
>>>>> what returns this command on server?
>>>>> python -c 'import netaddr; from dns import resolver; ip =
>>>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>>>> print resolver.zone_for_name(revn)'
>>>>>
>>>>>
>>>>> # python -c 'import netaddr; from dns import resolver; ip =
>>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>>> print resolver.zone_for_name(revn)'
>>>> 165.0.0.10.in-addr.arpa.
>>>> in-addr.arpa.
>>>>
>>>>
>>>> It looks that python-dns failed to find proper zone, what is supposed
>>>> to be authoritative zone for that record in your system?
&g
Re: [Freeipa-users] DNS reverse zone is not managed by this server
# python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print a.rrset.name'
0.0.10.in-addr.arpa.
On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti <mba...@redhat.com> wrote:
>
>
> On 27.12.2016 13:04, Maciej Drobniuch wrote:
>
> $ dig 0.0.10.in-addr.arpa
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;0.0.10.in-addr.arpa. IN A
>
> ;; AUTHORITY SECTION:
> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
> 1482653944 3600 900 1209600 3600
>
> ;; Query time: 197 msec
> ;; SERVER: 10.0.0.200#53(10.0.0.200)
> ;; WHEN: Tue Dec 27 13:02:24 CET 2016
> ;; MSG SIZE rcvd: 111
>
>
> Hmm, this query doesn't contain ANSWER section, that may be reason why
> python-dns failed.
>
> could you check with:
>
> python -c 'from dns import resolver; a =
> resolver.query("0.0.10.in-addr.arpa.",
> "SOA", "IN"); print a.rrset.name'
>
>
>
> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mba...@redhat.com> wrote:
>
>>
>>
>> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>>
>> Hi Martin!
>>
>> Thank you for your time!
>>
>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mba...@redhat.com> wrote:
>>
>>>
>>>
>>> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>>>
>>> Hi Martin
>>>
>>> Appreciate your help!
>>>
>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>>>
>>>> Hi Martin
>>>>
>>>> Thank you for reply.
>>>>
>>>> 1. The dig is returning proper PTR record. I've added it manually to
>>>> the zone and it's working.
>>>>
>>>>
>>>> I was asking for SOA and zone name, IMO there is nothing secret about
>>>> reverse zone name from private address space
>>>>
>>>> what returns this command on server?
>>>> python -c 'import netaddr; from dns import resolver; ip =
>>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>>> print resolver.zone_for_name(revn)'
>>>>
>>>>
>>>> # python -c 'import netaddr; from dns import resolver; ip =
>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>> print resolver.zone_for_name(revn)'
>>> 165.0.0.10.in-addr.arpa.
>>> in-addr.arpa.
>>>
>>>
>>> It looks that python-dns failed to find proper zone, what is supposed to
>>> be authoritative zone for that record in your system?
>>> How do your reverse zones look?
>>>
>> I have the reverse zone added.
>> 0.0.10.in-addr.arpa.
>>
>> Do you know maybe how python/ipa is determining what's the dns server for
>> the internal zone?
>> As far I understood this is not a "access rights issue". It's a DNS PTR
>> resolution problem with python(ipa's using python) ?
>>
>>
>> It doesn't care about resolver, python-dns is checking SOA records, it
>> removes labels from left and tries to find best match zone
>>
>> what returns dig 0.0.10.in-addr.arpa. SOA ?
>>
>>
>>
>>
>>>
>>>
>>>
>>> 2. The problem exists while adding host entries or A records with
>>>> "create reverse" option.
>>>>
>>>> That's why I asked to run dig, the code uses DNS system to determine
>>>> zone.
>>>>
>>>> 3. If I'll bind a host with ipa-client-install the PTR record gets
>>>> created in the reverse zone and it works
>>>>
>>>> Ok
>>>>
>>> Manually creating the PTR record works fine as well.
>>>
>>>>
>>>>
>>>> 4. The resolv.conf file has only the IPA server IP addres/localhost
>>>> added.
>>>>
>>>>
>>>> Have you changed it recently?
>>>>
>>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
>>> reverse zone.
>>> Now it's pointing to localhost. And I get
Re: [Freeipa-users] DNS reverse zone is not managed by this server
$ dig 0.0.10.in-addr.arpa
; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa. IN A
;; AUTHORITY SECTION:
0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
1482653944 3600 900 1209600 3600
;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE rcvd: 111
On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mba...@redhat.com> wrote:
>
>
> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>
> Hi Martin!
>
> Thank you for your time!
>
> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mba...@redhat.com> wrote:
>
>>
>>
>> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>>
>> Hi Martin
>>
>> Appreciate your help!
>>
>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com> wrote:
>>
>>>
>>>
>>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>>
>>> Hi Martin
>>>
>>> Thank you for reply.
>>>
>>> 1. The dig is returning proper PTR record. I've added it manually to the
>>> zone and it's working.
>>>
>>>
>>> I was asking for SOA and zone name, IMO there is nothing secret about
>>> reverse zone name from private address space
>>>
>>> what returns this command on server?
>>> python -c 'import netaddr; from dns import resolver; ip =
>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>> print resolver.zone_for_name(revn)'
>>>
>>>
>>> # python -c 'import netaddr; from dns import resolver; ip =
>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>> print resolver.zone_for_name(revn)'
>> 165.0.0.10.in-addr.arpa.
>> in-addr.arpa.
>>
>>
>> It looks that python-dns failed to find proper zone, what is supposed to
>> be authoritative zone for that record in your system?
>> How do your reverse zones look?
>>
> I have the reverse zone added.
> 0.0.10.in-addr.arpa.
>
> Do you know maybe how python/ipa is determining what's the dns server for
> the internal zone?
> As far I understood this is not a "access rights issue". It's a DNS PTR
> resolution problem with python(ipa's using python) ?
>
>
> It doesn't care about resolver, python-dns is checking SOA records, it
> removes labels from left and tries to find best match zone
>
> what returns dig 0.0.10.in-addr.arpa. SOA ?
>
>
>
>
>>
>>
>>
>> 2. The problem exists while adding host entries or A records with "create
>>> reverse" option.
>>>
>>> That's why I asked to run dig, the code uses DNS system to determine
>>> zone.
>>>
>>> 3. If I'll bind a host with ipa-client-install the PTR record gets
>>> created in the reverse zone and it works
>>>
>>> Ok
>>>
>> Manually creating the PTR record works fine as well.
>>
>>>
>>>
>>> 4. The resolv.conf file has only the IPA server IP addres/localhost
>>> added.
>>>
>>>
>>> Have you changed it recently?
>>>
>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
>> reverse zone.
>> Now it's pointing to localhost. And I get dig the PTRs. (I've manually
>> created the ptr)
>>
>> # dig -x 10.0.0.165
>>
>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>
>> ;; OPT PSEUDOSECTION:
>> ; E: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;165.0.0.10.in-addr.arpa. IN PTR
>>
>> ;; ANSWER SECTION:
>> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.
>>
>> ;; AUTHORITY SECTION:
>> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
>>
>>
>> This authority section looks suspicious, I would expect something like
>> 0.0.10.in-addr.arpa.
>>
>> Back to question about your reverse zones.
>>
> I've intentionally hid our internal ip space, sorry, good catch my finger
> has slipped :).
>
>
> So is the 0.0.10.in-addr.arpa. an authoritative
Re: [Freeipa-users] DNS reverse zone is not managed by this server
Hi Martin!
Thank you for your time!
On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mba...@redhat.com> wrote:
>
>
> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>
> Hi Martin
>
> Appreciate your help!
>
> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com> wrote:
>
>>
>>
>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>
>> Hi Martin
>>
>> Thank you for reply.
>>
>> 1. The dig is returning proper PTR record. I've added it manually to the
>> zone and it's working.
>>
>>
>> I was asking for SOA and zone name, IMO there is nothing secret about
>> reverse zone name from private address space
>>
>> what returns this command on server?
>> python -c 'import netaddr; from dns import resolver; ip =
>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>> print resolver.zone_for_name(revn)'
>>
>>
>> # python -c 'import netaddr; from dns import resolver; ip =
> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print
> resolver.zone_for_name(revn)'
> 165.0.0.10.in-addr.arpa.
> in-addr.arpa.
>
>
> It looks that python-dns failed to find proper zone, what is supposed to
> be authoritative zone for that record in your system?
> How do your reverse zones look?
>
I have the reverse zone added.
0.0.10.in-addr.arpa.
Do you know maybe how python/ipa is determining what's the dns server for
the internal zone?
As far I understood this is not a "access rights issue". It's a DNS PTR
resolution problem with python(ipa's using python) ?
>
>
>
> 2. The problem exists while adding host entries or A records with "create
>> reverse" option.
>>
>> That's why I asked to run dig, the code uses DNS system to determine zone.
>>
>> 3. If I'll bind a host with ipa-client-install the PTR record gets
>> created in the reverse zone and it works
>>
>> Ok
>>
> Manually creating the PTR record works fine as well.
>
>>
>>
>> 4. The resolv.conf file has only the IPA server IP addres/localhost added.
>>
>>
>> Have you changed it recently?
>>
> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
> reverse zone.
> Now it's pointing to localhost. And I get dig the PTRs. (I've manually
> created the ptr)
>
> # dig -x 10.0.0.165
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; E: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;165.0.0.10.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.
>
> ;; AUTHORITY SECTION:
> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
>
>
> This authority section looks suspicious, I would expect something like
> 0.0.10.in-addr.arpa.
>
> Back to question about your reverse zones.
>
I've intentionally hid our internal ip space, sorry, good catch my finger
has slipped :).
>
>
> ;; ADDITIONAL SECTION:
> freeipa1.cs.int. 1200 IN A 10.0.0.200
>
> ;; Query time: 3 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: czw gru 22 04:51:23 EST 2016
> ;; MSG SIZE rcvd: 124
>
>>
>>
>> Martin
>>
>>
>>
>> Cheers!
>> M.
>>
>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti <mba...@redhat.com> wrote:
>>
>>> Hello all :)
>>>
>>> On 20.12.2016 01:33, Maciej Drobniuch wrote:
>>>
>>> Hi All!
>>>
>>> I get the following message while adding a new hostname.
>>>
>>> "The host was added but the DNS update failed with: DNS reverse zone
>>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"
>>>
>>>
>>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165
>>> what will be in SOA answer?
>>>
>>> What is the name of reverse zone you have on IPA DNS server?
>>>
>>>
>>> Martin
>>>
>>>
>>> The reverse zone is configured and working.
>>> When I am manually adding the PTR record to the reverse zone - all OK
>>>
>>> While adding a new host, the A record is being created but the PTR
>>> fails with the message above.
>>>
>>> Reinstalling centos+IPA worked once but I had to reinstall again because
>>> of problems with kerberos(probably d
Re: [Freeipa-users] DNS reverse zone is not managed by this server
Hi Martin
Appreciate your help!
On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com> wrote:
>
>
> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>
> Hi Martin
>
> Thank you for reply.
>
> 1. The dig is returning proper PTR record. I've added it manually to the
> zone and it's working.
>
>
> I was asking for SOA and zone name, IMO there is nothing secret about
> reverse zone name from private address space
>
> what returns this command on server?
> python -c 'import netaddr; from dns import resolver; ip =
> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print
> resolver.zone_for_name(revn)'
>
>
> # python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.
2. The problem exists while adding host entries or A records with "create
> reverse" option.
>
> That's why I asked to run dig, the code uses DNS system to determine zone.
>
> 3. If I'll bind a host with ipa-client-install the PTR record gets created
> in the reverse zone and it works
>
> Ok
>
Manually creating the PTR record works fine as well.
>
>
> 4. The resolv.conf file has only the IPA server IP addres/localhost added.
>
>
> Have you changed it recently?
>
Yes, it pointed to outside 8.8.8.8, so the OS did not see the local reverse
zone.
Now it's pointing to localhost. And I get dig the PTRs. (I've manually
created the ptr)
# dig -x 10.0.0.165
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.
;; AUTHORITY SECTION:
1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
;; ADDITIONAL SECTION:
freeipa1.cs.int. 1200 IN A 10.0.0.200
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: czw gru 22 04:51:23 EST 2016
;; MSG SIZE rcvd: 124
>
>
> Martin
>
>
>
> Cheers!
> M.
>
> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti <mba...@redhat.com> wrote:
>
>> Hello all :)
>>
>> On 20.12.2016 01:33, Maciej Drobniuch wrote:
>>
>> Hi All!
>>
>> I get the following message while adding a new hostname.
>>
>> "The host was added but the DNS update failed with: DNS reverse zone
>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"
>>
>>
>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165
>> what will be in SOA answer?
>>
>> What is the name of reverse zone you have on IPA DNS server?
>>
>>
>> Martin
>>
>>
>> The reverse zone is configured and working.
>> When I am manually adding the PTR record to the reverse zone - all OK
>>
>> While adding a new host, the A record is being created but the PTR fails
>> with the message above.
>>
>> Reinstalling centos+IPA worked once but I had to reinstall again because
>> of problems with kerberos(probably dependencies).
>>
>> Not sure what is the root cause of the issue.
>>
>> VERSION: 4.4.0, API_VERSION: 2.213
>>
>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42
>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Any help appreciated!
>> --
>> Best regards
>>
>> Maciej Drobniuch
>> Network Security Engineer
>> Collective-sense LLC
>>
>>
>>
>>
>
>
> --
> Best regards
>
> Maciej Drobniuch
> Network Security Engineer
> Collective-sense LLC
>
>
>
--
Best regards
Maciej Drobniuch
Network Security Engineer
2410 Camino Ramon, Suite 129
San Ramon, CA 94583
--
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] DNS reverse zone is not managed by this server
Hi Martin Thank you for reply. 1. The dig is returning proper PTR record. I've added it manually to the zone and it's working. 2. The problem exists while adding host entries or A records with "create reverse" option. 3. If I'll bind a host with ipa-client-install the PTR record gets created in the reverse zone and it works 4. The resolv.conf file has only the IPA server IP addres/localhost added. Cheers! M. On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti <mba...@redhat.com> wrote: > Hello all :) > > On 20.12.2016 01:33, Maciej Drobniuch wrote: > > Hi All! > > I get the following message while adding a new hostname. > > "The host was added but the DNS update failed with: DNS reverse zone > in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" > > > IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 what > will be in SOA answer? > > What is the name of reverse zone you have on IPA DNS server? > > > Martin > > > The reverse zone is configured and working. > When I am manually adding the PTR record to the reverse zone - all OK > > While adding a new host, the A record is being created but the PTR fails > with the message above. > > Reinstalling centos+IPA worked once but I had to reinstall again because > of problems with kerberos(probably dependencies). > > Not sure what is the root cause of the issue. > > VERSION: 4.4.0, API_VERSION: 2.213 > > CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC > 2015 x86_64 x86_64 x86_64 GNU/Linux > > Any help appreciated! > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-sense LLC > > > > -- Best regards Maciej Drobniuch Network Security Engineer Collective-sense LLC -- 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] DNS reverse zone is not managed by this server
Hi All! I get the following message while adding a new hostname. "The host was added but the DNS update failed with: DNS reverse zone in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" The reverse zone is configured and working. When I am manually adding the PTR record to the reverse zone - all OK While adding a new host, the A record is being created but the PTR fails with the message above. Reinstalling centos+IPA worked once but I had to reinstall again because of problems with kerberos(probably dependencies). Not sure what is the root cause of the issue. VERSION: 4.4.0, API_VERSION: 2.213 CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Any help appreciated! -- Best regards Maciej Drobniuch Network Security Engineer Collective-sense LLC -- 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
