Re: [Freeipa-users] Please Provide the IPA Client Configuration Doc for Ubuntu 12.04, 14.04

2016-07-19 Thread Visakh MV 
Hi,


first case: As per your direction, things are going well even if we are
facing some issues as well. even like once logged in to ipa-client machine
with ipa user with certain privilege after that while using terminal " TAB"
and " Arrow " keys have not working. due to the same we can not use the
system properly.

second case: if any policy would have to edit at any certain reason then it
will not update it with at real time, it could take some time to update new
changes. is there any command to update at real time?

third case: what are the sudo rule option?

only one sudo option you have shared across the doc " !authenticate " has
working fine. and it will not take other custom options.

example:  I added one sudo option inside sudo rule like " rootprivilege "
but its showing one error on client machine while checking allowed
commands.

Please revert back.

On Fri, Jul 15, 2016 at 10:41 AM, Visakh MV  wrote:

> Hi Team,
>
> Could you provide the client setup guide for Ubuntu systems. And we are
> using FreeIPA 4.2.0 version.  it's been a while trying to find the document
> for Ubuntu with latest version FreeIPA Server, even now can not find the
> doc. so kindly provide the same doc via mail as soon as good.
>
> even if tried some solution that could find out from internet as well but
> still its not help us.
>
> --
>
> Thanks & Regards,
>
> *Visakh m.v*
>
> *Support Engineer*
>
> Soffit Infrastructure Services (P) Ltd | Raj Bhavan | Power House Road |
> Palarivattom|Kochi-25 | Kerala | India.
>
> (M) +91-9497714447|(O) 0484-3045663,0484-3931393|Web:www.soffit.in
>
> Managed Services | Technical Services | Infrastructure Consulting | Audits
> & Assessments
>
> DISCLAIMER : This email, which includes any attachments, is confidential,
> may be privileged and is intended solely for the use of the named
> recipient(s). If you are not the intended recipient, do not disclose,
> distribute, or retain it, and please notify the sender immediately and
> delete the e-mail. E-mail is not necessarily secure or error free. It is
> your responsibility to ensure that e-mails are virus free. No one may
> conclude a contract on behalf of SOFFIT by e-mail without express written
> confirmation by a duly authorised representative of SOFFIT. Any views
> expressed in this e-mail are not necessarily those of SOFFIT. SOFFIT
> accepts no responsibility for any loss or damages arising in any way from
> the use of this e-mail as a means of communication.
>



-- 

Thanks & Regards,

*Visakh m.v*

*Support Engineer*

Soffit Infrastructure Services (P) Ltd | Raj Bhavan | Power House Road |
Palarivattom|Kochi-25 | Kerala | India.

(M) +91-9497714447|(O) 0484-3045663,0484-3931393|Web:www.soffit.in

Managed Services | Technical Services | Infrastructure Consulting | Audits
& Assessments

DISCLAIMER : This email, which includes any attachments, is confidential,
may be privileged and is intended solely for the use of the named
recipient(s). If you are not the intended recipient, do not disclose,
distribute, or retain it, and please notify the sender immediately and
delete the e-mail. E-mail is not necessarily secure or error free. It is
your responsibility to ensure that e-mails are virus free. No one may
conclude a contract on behalf of SOFFIT by e-mail without express written
confirmation by a duly authorised representative of SOFFIT. Any views
expressed in this e-mail are not necessarily those of SOFFIT. SOFFIT
accepts no responsibility for any loss or damages arising in any way from
the use of this e-mail as a means of communication.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Unable to ssh after establishing trust

2016-07-19 Thread Simpson Lachlan 
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of pgb205
Sent: Wednesday, 20 July 2016 5:28 AM
To: Sumit Bose
Cc: Freeipa-users
Subject: Re: [Freeipa-users] Unable to ssh after establishing trust

well...I'm not sure what I changed, if anything, but I am able to login with my 
AD credentials. I have restarted ipa server and cleared sss_cache, so maybe 
that helped.

A few other things still remain though:

right now im logging in as jsmith@ADDOMAIN.LOCAL
I would want it to be either jsm...@addomain.com
or better yet
jsmith  --without specifying the domain name.

How can this be accomplished?

[Lachlan Simpson]


You are looking for the default_domain_suffix setting in the sssd stanza of 
/etc/sssd/sssd.conf

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-user-ids.html

Cheers
L.



thanks


From: Sumit Bose mailto:sb...@redhat.com>>
To: pgb205 mailto:pgb...@yahoo.com>>
Cc: Freeipa-users mailto:freeipa-users@redhat.com>>
Sent: Tuesday, July 19, 2016 3:33 AM
Subject: Re: [Freeipa-users] Unable to ssh after establishing trust

On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
>
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
>
> /etc/hosts:
> Reachable_IP_BOX  172.10.10.1
> DC1172.10.10.1
> DC2172.10.10.1
> ...
> ...

The IP address should come first, please see man hosts for details.

>
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'

Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?

>
>
> Additionally I have configured
> [domain/ipa.internal]
>  with
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
>
>
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting  extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.

Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.

bye,

Sumit

>
>
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
>
> thanks
> ━━━
> From: Sumit Bose mailto:sb...@redhat.com>>
> To: pgb205 mailto:pgb...@yahoo.com>>
> Cc: Sumit Bose mailto:sb...@redhat.com>>; Freeipa-users 
> mailto:freeipa-users@redhat.com>>
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> >  From: pgb205 mailto:pgb...@yahoo.com>>
> >  To: Sumit Bose mailto:sb...@redhat.com>>
> >  Sent: Tuesday, July 12, 2016 2:12 PM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >
> > Sumit, thanks for replying
> > So the first issue is my fault, probably from when I was sanitizing logs.
> > our active directory domain is ad_domain.local, but users would expect to
> login as userid@ad_domain.com or just userid.for 
> ipa the kerberos realm is
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> > ewr-fipa_server used to be old trial server so I am not sure why it's still
> in the dns lookup results. I'll check this part further.
> > Lastly. only the connection to one of the domain controllers on AD side is
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf,
> a connection to this single, accessible domain controller. Are there any other
> files where I would needto lock down the connections between ipa->ad so that
> all traffic goes to specific active directory domain controller?
> > thanks again for replying so quickly.
>
> Currently it is not possible to specify individual AD DC SSSD on the IPA
> server should talk to. We have ticket
> https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
> later versions of SSSD.
>
> Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
> get a list of AD DC, then picks one to get the next nearest site for the
> IPA domain and finally tries to lookup a DC from the matching site (if
> any).
>
> According to your logs SSSD was able to find 18 DCs with the SRV lookup.
> A call like
>
>dig SRV _ldap._tcp.ad_doma

Re: [Freeipa-users] HBAC and AD users

2016-07-19 Thread Lachlan Musicman 
On 19 July 2016 at 16:40, Jakub Hrozek  wrote:

> On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > I think the thing that frustrates the most is that id u...@domain.com is
> > returning correct data on both but they can't loginand I can't even
> > show that this is the case because now they can login. Difficult to
> > reproduce :/
>
> Debugging from HBAC should at least tell you why the rules didn't
> match...
>


Sorry, I should have been clear - the issue is exactly the same. HBAC
rejected the user because they weren't in the correct groups, but sssd
hadn't got the correct number of groups from the AD server, and had missed
the group in question.

This is the user that reported the issue yesterday morning:

[root@vmpr-linuxidm ~]# id "lupat richard"@petermac.org.au | tr "," "\n" |
wc -l
22

Here are the relevant lines from the log.

 (Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_attrs_to_rule] (0x1000): Processing rule [Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_user_attrs_to_rule] (0x1000): Processing users for rule [Computing
Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [12] groups for [Lupat Richard]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research Bioinformatics Students
Reading Group,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Assistants,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf-Cluster,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=External - Exchange 2010
Users,OU=SOE & IT,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=VPN Access - General,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Mac Users,OU=!Exchange
Distribution Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf - Team,OU=!Security
Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Bioinformatics,OU=!Exchange Distribution Groups,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing
CN=DM_Outlook_Find,CN=Users,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected groups second component, got Users
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=RES_BioInformatics,OU=Department
Groups,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN

Re: [Freeipa-users] IPA certificates expired, please help!

2016-07-19 Thread Linov Suresh 
Great! That worked, and I was successfully renewed the certificates on the
IPA server and I was trying to create a IPA replica server and got an error,
[root@neit-lab ~]# ipa-replica-install --setup-ca --setup-dns
--no-forwarders --skip-conncheck
/var/lib/ipa/replica-info-neit-lab.teloip.net.gpg Directory Manager
(existing master) password: Configuring NTP daemon (ntpd) [1/4]: stopping
ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring
directory server for the CA (pkids): Estimated time 30 seconds [1/3]:
creating directory server user [2/3]: creating directory server instance
[3/3]: restarting directory server Done configuring directory server for
the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3
minutes 30 seconds [1/17]: creating certificate server user [2/17]:
creating pki-ca instance [3/17]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl
/usr/bin/pkisilent ConfigureCA -cs_hostname neit-lab.teloip.net -cs_port
9445 -client_certdb_dir /tmp/tmp-QAXI9A -client_certdb_pwd 
-preop_pin UpMxkDYjV90WLL041tDU -domain_name IPA -admin_user admin
-admin_email root@localhost -admin_password  -agent_name
ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
CN=ipa-ca-agent,O=TELOIP.NET -ldap_host neit-lab.teloip.net -ldap_port 7389
-bind_dn cn=Directory Manager -bind_password  -base_dn o=ipaca
-db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd  -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=TELOIP.NET
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=TELOIP.NET
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=TELOIP.NET
-ca_server_cert_subject_name CN=neit-lab.teloip.net,O=TELOIP.NET
-ca_audit_signing_cert_subject_name CN=CA Audit,O=TELOIP.NET
-ca_sign_cert_subject_name CN=Certificate Authority,O=TELOIP.NET -external
false -clone true -clone_p12_file ca.p12 -clone_p12_password 
-sd_hostname caer.teloip.net -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password  -clone_start_tls true -clone_uri
https://caer.teloip.net:443' returned non-zero exit status 255 Your system
may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to
clean up. Configuration of CA failed [root@neit-lab ~]#

I did a clean up using /usr/sbin/ipa-server-install --uninstall but it
wasn't helpful. Wondering if you can help us on this,




On Tue, Jul 19, 2016 at 10:50 AM, Rob Crittenden 
wrote:

> Linov Suresh wrote:
>
>> I have followed Redhat official documentation,
>> https://access.redhat.com/solutions/643753 for certificate renewal,
>> which says *add: usercertificate. (step 12)*
>> *
>> *
>> While on the other hand FreeIPA official documentaion
>> http://www.freeipa.org/page/IPA_2x_Certificate_Renewal , say to *add:
>> usercertificate;binary*
>>
>> Just wondering if we need to*add *the certificate? or*replace* the
>> existing certificate and which format do we need to use? *pem* or *der*.
>>
>> We already successfully renewed the certificates about months back, but
>> they were expired about 6 months back and we were not able to renew till
>> now, and is affected our production environment.
>>
>> Pleas help us.
>>
>
> You shouldn't have to mess with these values at all. In 3.0 this is
> handled somewhat automatically.
>
> I'd restart the CA, then certmonger and see if the communication error
> goes away for the CA subservice certificates (the internal error).
>
> # service pki-cad restart
> 
> # service certmonger restart
>
> I find it very strange that the certificates were set to expire yesterday
> but it isn't a show-stopper necessarily assuming you can get the CA back up.
>
> Assuming you can, then go back in time again, this time just a few days
> and try renewing the LDAP and Apache server certs again.
>
> rob
>
>
>> On Tue, Jul 19, 2016 at 9:27 AM, Linov Suresh > > wrote:
>>
>> We have cloned and created another virtual server from the template.
>> Surprisingly this server certificates were also expired at the same
>> time as the previous, just lasted for a day.
>> This issue has something to do with the kerberos tickets?
>>
>> I am new to IPA and your help is highly appreciated.
>>
>> On Mon, Jul 18, 2016 at 12:37 PM, Linov Suresh
>> mailto:linov.sur...@gmail.com>> wrote:
>>
>> *Update: my webserver and LDAP certificates were expired at
>> 2016-07-18 15:54:36 UTC and the certificates are in
>> CA_UNREACHABLE state.*
>> *
>> *
>> *Could you please help us?
>> *
>>
>> [root@caer tmp]# getcert list
>> Number of certificates and requests being tracked: 8.
>> Request ID '20111214223243':
>>  status: CA_UNREACHABLE
>>

Re: [Freeipa-users] ipa trust-fetch-domains failing.

2016-07-19 Thread pgb205 
Alexander, 
regarding your comment about putting stanza on each client.In our case clients 
are not on the same network as the Active Directory domain controller.My plan 
was to have the Freeipa server as the bridge-head server 
AD DC <-> FIPA server  <-> Linux clients
as it sits on the network that has access to both environments.
1. If each client has to go out to AD DC to authenticate than what is the 
purpose of FreeIPA server ? I thought it would act as a proxy to forward 
authentication requests to AD.
2. What would be my options in the above situation to get around this 
requirement -- direct connectivity to Active Directoryenvironment by clients?
thanks 

  From: Alexander Bokovoy 
 To: pgb205  
Cc: Freeipa-users 
 Sent: Monday, July 4, 2016 12:02 AM
 Subject: Re: [Freeipa-users] ipa trust-fetch-domains failing.
   
On Mon, 04 Jul 2016, pgb205 wrote:
>Selinux is disabled on the server. However, I managed to fix the problem buy 
>adding the AD.DOMAIN {} 
>section to my krb5.conf in addition to IPA.DOMAIN {}. So it now looks like 
>[realms]IPA.DOMAIN{master_kdc=ipa.dc.ipadomain:portauth_kdc=ipa.dc.ipadomain:port...}
>AD.DOMAIN{master_kdc=ad.dc.addomain:portauth_kdc=ad.dc.addomain:port...}
>this had the desired effect although I am not 100 clear on why this worked.
>My theory is that we have multiple domain controllers and of course the
>addomain.com forward zone that was configured prior returns a full
>list. Only the ports to the one ad.dc.addomain.com server have been
>opened between the ipa and ad servers and so when trust command is
>executed connection goes to some domain controller that IPA can't
>connect to, eventually generating an error.  Just a theory for now.
It is a totally plausible theory -- when we do trust-fetch-domains, we
try to use Kerberos authentication against AD DCs. Forcing IPA master to
use specific domain controller via krb5.conf should help here.

Note that you'll need to have a similar stanza on each IPA client as
well because authentication happens directly to AD DCs and SSSD on IPA
clients will have to do the same job using AD user credentials in case
of password logons.



>thanks
>
>      From: Alexander Bokovoy 
> To: pgb205 
>Cc: "bentech4...@gmail.com" ; Freeipa-users 
>
> Sent: Friday, July 1, 2016 3:37 AM
> Subject: Re: [Freeipa-users] ipa trust-fetch-domains failing.
>
>On Thu, 30 Jun 2016, pgb205 wrote:
>>Ben, do you mind sharing your solution as I am affected by the exact same 
>>error when fetching AD domains.
>I'm currently on vacation and don't have access to my lab, but you need
>to check if there are any problems with SELinux. 'ipa
>trust-fetch-domains' calls out via DBus to another script. It is
>functionally equivalent to the following command run as root:
>
># oddjob_request -s com.redhat.idm.trust -o / -i com.redhat.idm.trust 
>com.redhat.idm.trust.fetch_domains ad.test
>
>where ad.test is your AD root domain.
>
>If you add 'log level = 100' in /usr/share/ipa/smb.conf.empty, then this
>run will generate a lot of debug information.
>
>
>-- 
>/ Alexander Bokovoy
>
>
>

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


-- 
/ Alexander Bokovoy


  -- 
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] FreeIPA SSL certificates installed to multiple hosts

2016-07-19 Thread Rob Crittenden 

Jeremy Utley wrote:

Hello all!

We're looking at replacing a lot of our currently self-signed internal
SSL certificates in our infrastructure with certificates generated by
the FreeIPA CA.  However, I've run into something that I haven't been
able to find documented as of yet, and I'm hoping some of you can point
me in the right direction.  Some of our internal SSL sites are
load-balanced between multiple hosts, so we end up with the same SSL/Key
installed to each host.  For example:

hostname.domain.com  is hosted on hostA and
hostB.

Both hostA and hostB have the certs at
/etc/httpd/certs/hostname.domain.com/hostname.crt
, and the private key at
/etc/httpd/certs/hostname.domain.com/hostname.key


I would expect I can have both hostA and hostB be able to work with the
FreeIPA certificates by adding additional ipa host-add-managedby and ipa
service-add-host commands, to specify both hostA and hostB.  However,
from my understanding, running the "ipa-getcert request" command on
hostA will put the certs on hostA only, and I'd need the same certs on
both hostA and hostB.  Is there a special ipa-getcert incantation that
can retrieve the already-issued certificate files, and allow them to be
managed by FreeIPA on both hosts?  Or is there another recommended way
of doing this?

Thanks for any info you can give me!



IPA doesn't have any provision for sharing keys between machines. I 
think you'd need to manage it similar to the way you probably do now: 
manually copying files around.


What you can do is setup one machine to "own" the certs and keys and do 
the renewals via certmonger, but beyond that you're on your own.


rob

--
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] FreeIPA SSL certificates installed to multiple hosts

2016-07-19 Thread Jeremy Utley 
Hello all!

We're looking at replacing a lot of our currently self-signed internal SSL
certificates in our infrastructure with certificates generated by the
FreeIPA CA.  However, I've run into something that I haven't been able to
find documented as of yet, and I'm hoping some of you can point me in the
right direction.  Some of our internal SSL sites are load-balanced between
multiple hosts, so we end up with the same SSL/Key installed to each host.
For example:

hostname.domain.com is hosted on hostA and hostB.

Both hostA and hostB have the certs at /etc/httpd/certs/
hostname.domain.com/hostname.crt, and the private key at /etc/httpd/certs/
hostname.domain.com/hostname.key

I would expect I can have both hostA and hostB be able to work with the
FreeIPA certificates by adding additional ipa host-add-managedby and ipa
service-add-host commands, to specify both hostA and hostB.  However, from
my understanding, running the "ipa-getcert request" command on hostA will
put the certs on hostA only, and I'd need the same certs on both hostA and
hostB.  Is there a special ipa-getcert incantation that can retrieve the
already-issued certificate files, and allow them to be managed by FreeIPA
on both hosts?  Or is there another recommended way of doing this?

Thanks for any info you can give me!

Jeremy Utley
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Unable to ssh after establishing trust

2016-07-19 Thread pgb205 
well...I'm not sure what I changed, if anything, but I am able to login with my 
AD credentials. I have restarted ipa server and cleared sss_cache, so maybe 
that helped.
A few other things still remain though:
right now im logging in as jsmith@ADDOMAIN.LOCALI would want it to be either 
jsmith@ADDOMAIN.COMor better yetjsmith  --without specifying the domain name.
How can this be accomplished?
thanks

  From: Sumit Bose 
 To: pgb205  
Cc: Freeipa-users 
 Sent: Tuesday, July 19, 2016 3:33 AM
 Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
   
On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
> 
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
> 
> /etc/hosts:
> Reachable_IP_BOX  172.10.10.1
> DC1                            172.10.10.1
> DC2                            172.10.10.1
> ...
> ...

The IP address should come first, please see man hosts for details.

> 
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'

Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?

> 
> 
> Additionally I have configured 
> [domain/ipa.internal]
>      with 
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
> 
> 
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting  extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.

Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.

bye,
Sumit

> 
> 
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
> 
> thanks
> ━━━
> From: Sumit Bose 
> To: pgb205 
> Cc: Sumit Bose ; Freeipa-users 
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> 
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> >      From: pgb205 
> >  To: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 2:12 PM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >  
> > Sumit, thanks for replying
> > So the first issue is my fault, probably from when I was sanitizing logs. 
> > our active directory domain is ad_domain.local, but users would expect to
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> > ewr-fipa_server used to be old trial server so I am not sure why it's still
> in the dns lookup results. I'll check this part further.
> > Lastly. only the connection to one of the domain controllers on AD side is
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf,
> a connection to this single, accessible domain controller. Are there any other
> files where I would needto lock down the connections between ipa->ad so that
> all traffic goes to specific active directory domain controller?
> > thanks again for replying so quickly.
> 
> Currently it is not possible to specify individual AD DC SSSD on the IPA
> server should talk to. We have ticket
> https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
> later versions of SSSD.
> 
> Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
> get a list of AD DC, then picks one to get the next nearest site for the
> IPA domain and finally tries to lookup a DC from the matching site (if
> any).
> 
> According to your logs SSSD was able to find 18 DCs with the SRV lookup.
> A call like
> 
>    dig SRV _ldap._tcp.ad_domain.local
> 
> on the IPA server should return the same list of 18 DCs.
> 
> As a work-around, or better a hack, you might want to try to set the IP
> address of all the 18 DC returned to the IP address of the only
> accessible DC in /etc/hosts. This way SSSD should have no chance to
> connect to a different DC.
> 
> bye,
> 
> Sumit
> 
> >
> >      From: Sumit Bose 
> >  To: pgb205 
> > Cc: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 5:37 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> > 
> > On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > > Sumit, 
> > > sssd log files attached with debug=10 in all sections.I have attempted
> several logins for comparison as well as kinit commands
> >
> > I came across two issues in the logs.
> >
> > First it looks like you use 'user@AD_DOMA

Re: [Freeipa-users] AD trust with POSIX attributes

2016-07-19 Thread Justin Stephenson 

Hello,

When adding the AD trust using 'ipa-ad-trust-posix' range type then IPA 
will search AD for the ID space of existing POSIX attributes to 
automatically create a suitable ID range inside IPA.


You can check the exact steps and attributes searched by looking at the 
add_range function definition in 
/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py


I would suggest reviewing the output of 'ipa idrange-find' to confirm 
that the range matches up with the uid and gidNumbers of your AD 
environment.


Kind regards,
Justin Stephenson

On 07/19/2016 09:44 AM, Jan Karásek wrote:

Hi,

I am still fighting with storing user's POSIX attributes in AD. Please 
can anybody provide some simple reference settings of IPA-AD trust 
where users are able to get uid from AD - not from IPA ID pool ?


I have tried to set values of attributes before and after creating 
trust, I have tried different sssd setting but I'm still getting uid 
from  IPA idrange pool instead of from AD user's attribute.


What exactly is IPA checking when it tries to decide what type of 
trust will be set - ['ipa-ad-trust-posix', 'ipa-ad-trust'] ?


Do I have to mandatory fill some AD user's attributes to get it work ? 
Currently I'am testing just with uidNumber and gidNumber.


There is almost no documentation about this topic so I don't know what 
else I can try ...


Thanks for help,

Jan



Date: Tue, 21 Jun 2016 21:38:15 +0200
From: Jakub Hrozek 
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] AD trust with POSIX attributes
Message-ID: <20160621193815.GS29512@hendrix>
Content-Type: text/plain; charset=iso-8859-1

On Tue, Jun 21, 2016 at 01:55:54PM +0200, Jan Kar?sek wrote:
> Hi all,
>
> I have a questions about IPA with AD forest trust. What I am trying 
to do is setup environment, where all informations about users are 
stored in one place - AD. I would like to read at least uid, home, 
shell and sshkey from AD.

>
> I have set up trust with this parameters:
>
> ipa trust-add EXAMPLE.TT --type=ad --range-type=ipa-ad-trust-posix 
--admin=administrator


Did you add the POSIX attributes to AD after creating the trust maybe?

>
> [root@ipa1 ~]# ipa idrange-show EXAMPLE.TT_id_range
> Range name: EXAMPLE.TT_id_range
> First Posix ID of the range: 139200
> Number of IDs in the range: 20
> Domain SID of the trusted domain: 
S-1-5-21-4123312533-990676102-3576722756

> Range type: Active Directory trust range with POSIX attributes
>
>
> I have set attributes in AD for u...@example.tt
> - uidNumber -1
> - homeDirectory -/home/user
> - loginShell - /bin/bash
>
> Trust itself works fine. I can do kinit with u...@example.tt , I can 
run id and getent passwd u...@example.tt and I can use u...@example.tt 
for ssh.

>
> Problem is, that I am not getting uid from AD but from idrange:
>
> uid=1392001107(u...@example.tt)
>
> Also I have tried to switch off id mapping in sssd.conf with 
ldap_id_mapping = true in sssd.conf but no luck.


This has no effect, in IPA-AD trust scenario, the id mapping properties
are managed on the server.

>
> I know, that it is probably better to use ID views for this, but in 
our case we need to set centrally managed environment, where all users 
information are externally inserted to AD from HR system - included 
POSIX attributes and we need IPA to read them from AD.


I think idviews are better for overriding POSIX attributes for a
specific set of hosts, but in your environment, it sounds like you want
to use the POSIX attributes across the board.

>
> So my questions are:
>
> Is it possible to read user's POSIX attributes directly from AD - 
namely uid ?


Yes

> Which atributes can be stored in AD ?

Homedir is a bit special, for backwards compatibility the
subdomains_homedir takes precedence. The others should be read from AD.

I don't have the environment set at the moment, though, so I'm operating
purely from memory.

> Am I doing something wrong ?
>
> my sssd.conf:
> [domain/a.example.tt]
> debug_level = 5
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = a.example.tt
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = ipa1.a.example.tt
> chpass_provider = ipa
> ipa_server = ipa1.a.example.tt
> ipa_server_mode = True
> ldap_tls_cacert = /etc/ipa/ca.crt
> #ldap_id_mapping = true
> #subdomain_inherit = ldap_user_principal
> #ldap_user_principal = nosuchattribute
>
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
>
> domains = a.example.tt
> [nss]
> debug_level = 5
> homedir_substring = /home
> enum_cache_timeout = 2
> entry_negative_timeout = 2
>
>
> [pam]
> debug_level = 5
> [sudo]
>
> [autofs]
>
> [ssh]
> debug_level = 4
> [pac]
>
> debug_level = 4
> [ifp]
>
> Thanks,
> Jan









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

Re: [Freeipa-users] Unable to ssh after establishing trust

2016-07-19 Thread pgb205 
Sorry, I typed things out instead of copy/paste
my etc hosts looks like:

search  ad.local127.0.0.1       localhost
# The following lines are desirable for IPv6 capable hosts::1     localhost 
ip6-localhost ip6-loopbackff02::1 ip6-allnodesff02::2 ip6-allrouters
10.10.10.1         ipa_server.ipa.internal    ipa_server172.19.10.10     
ad_server1.ad.local172.19.10.10     ad_server2.ad.local172.19.10.10     
ad_server3.ad.local
If you want I can send you the sssd logs again

  From: Sumit Bose 
 To: pgb205  
Cc: Freeipa-users 
 Sent: Tuesday, July 19, 2016 3:33 AM
 Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
   
On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
> 
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
> 
> /etc/hosts:
> Reachable_IP_BOX  172.10.10.1
> DC1                            172.10.10.1
> DC2                            172.10.10.1
> ...
> ...

The IP address should come first, please see man hosts for details.

> 
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'

Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?

> 
> 
> Additionally I have configured 
> [domain/ipa.internal]
>      with 
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
> 
> 
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting  extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.

Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.

bye,
Sumit

> 
> 
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
> 
> thanks
> ━━━
> From: Sumit Bose 
> To: pgb205 
> Cc: Sumit Bose ; Freeipa-users 
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> 
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> >      From: pgb205 
> >  To: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 2:12 PM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >  
> > Sumit, thanks for replying
> > So the first issue is my fault, probably from when I was sanitizing logs. 
> > our active directory domain is ad_domain.local, but users would expect to
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> > ewr-fipa_server used to be old trial server so I am not sure why it's still
> in the dns lookup results. I'll check this part further.
> > Lastly. only the connection to one of the domain controllers on AD side is
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf,
> a connection to this single, accessible domain controller. Are there any other
> files where I would needto lock down the connections between ipa->ad so that
> all traffic goes to specific active directory domain controller?
> > thanks again for replying so quickly.
> 
> Currently it is not possible to specify individual AD DC SSSD on the IPA
> server should talk to. We have ticket
> https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
> later versions of SSSD.
> 
> Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
> get a list of AD DC, then picks one to get the next nearest site for the
> IPA domain and finally tries to lookup a DC from the matching site (if
> any).
> 
> According to your logs SSSD was able to find 18 DCs with the SRV lookup.
> A call like
> 
>    dig SRV _ldap._tcp.ad_domain.local
> 
> on the IPA server should return the same list of 18 DCs.
> 
> As a work-around, or better a hack, you might want to try to set the IP
> address of all the 18 DC returned to the IP address of the only
> accessible DC in /etc/hosts. This way SSSD should have no chance to
> connect to a different DC.
> 
> bye,
> 
> Sumit
> 
> >
> >      From: Sumit Bose 
> >  To: pgb205 
> > Cc: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 5:37 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> > 
> > On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > > Sumit, 
> > > sssd log files attached with debug=10 in all sections.I have attempted
> several logins for comparison as well as kinit commands
> >
> > I came across t

[Freeipa-users] Struggling to remove redundant RUV records

2016-07-19 Thread Bob Hinton 
Hi,

We had to replace a failed replica "ipa003.mgmt.prod.local".
Unfortunately, deleting the old copy prior to creating the replacement
doesn't seem to have worked and we're getting lots of errors like :-

attrlist_replace - attr_replace (nsslapd-referral,
ldap://ipa003.mgmt.prod.local:389 ... failed.

In the dirsrv logs.

One problem is that there are now two RUVs for ipa003.mgmt.prod.local.
How do I identify which is the live one so I can delete the redundant one ?

I'd also like to delete all the old "unable to decode" replicas. I found
a posting with an ldapsearch (see below), but this seems to give numbers
that don't match the replica IDs. Do I need to translate the search
results in some fashion or use a different search ?

Many Thanks

Bob Hinton

-sh-4.2$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

-sh-4.2$ ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

sh-4.2$ sudo ipa-replica-manage list-ruv
Directory Manager password:

unable to decode: {replica 15} 568d15720002000f 568d15720002000f
unable to decode: {replica 13} 568ed0a90001000d 56ebea6b0001000d
unable to decode: {replica 14} 568d16ea000e 56ab57950005000e
ipa002.mgmt.prod.local:389: 17
ipa001.mgmt.paas.local:389: 22
ipa003.mgmt.paas.local:389: 26
ipa002.mgmt.paas.local:389: 24
ipa002.mgmt.paas.local:389: 25
ipa003.mgmt.prod.local:389: 23
ipa003.mgmt.prod.local:389: 18
ipa001.mgmt.prod.local:389: 19
sh-4.2$ !996
sudo ipa-replica-manage clean-ruv 13
Directory Manager password:

unable to decode: {replica 15} 568d15720002000f 568d15720002000f
unable to decode: {replica 13} 568ed0a90001000d 56ebea6b0001000d
unable to decode: {replica 14} 568d16ea000e 56ab57950005000e
Replica ID 13 not found
sh-4.2$ !1000
ldapsearch -D "cn=Directory Manager" -W -h ipa003.mgmt.prod.local -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 1485
nsds50ruv: {replicageneration} 54be65640060
nsds50ruv: {replica 1485 ldap://ipa003.mgmt.prod.local:389} 5787b6e
nsds50ruv: {replica 1395 ldap://ipa001.mgmt.prod.local:389} 567ab7a
nsds50ruv: {replica 1490 ldap://ipa001.mgmt.paas.local:389} 5787aef
nsds50ruv: {replica 1495 ldap://ipa001.mgmt.paas.local:389} 578660e
nsds50ruv: {replica 1280 ldap://ipa002.mgmt.prod.local:389} 567949c
nsds50ruv: {replica 71 ldap://ipa4-03.local:389} 5617ba4d004700
nsds50ruv: {replica 1285 ldap://ipa001.mgmt.prod.local:389} 567804c
nsds50ruv: {replica 1290 ldap://ipa4-02.local:389} 561bb7bc050a
nsds50ruv: {replica 1295 ldap://ipa4-01.local:389} 561ba643050f
nsds50ruv: {replica 96 ldap://ipa0001-01.local:7389} 54be656e00
nsds50ruv: {replica 76 ldap://ipa4-rep.local:389} 56142cde004c0
nsds50ruv: {replica 81 ldap://ipa0001-03.local:7389} 54c25ac600
nsds50ruv: {replica 86 ldap://ipa0001-02.local:7389} 54c12c1d00
nsds50ruv: {replica 91 ldap://ipa0001-03.local:7389} 54bf475b00
nsds50ruv: {replica 97 ldap://ipa0001-02.local:7389} 54be656b00
nsds50ruv: {replica 1096 ldap://ipa3-rhel6.local:7389} 560d7d77
nsds50ruv: {replica 1196 ldap://ip4-rhel7.local:389} 56137c3104
nsds50ruv: {replica 1191 ldap://ipa4-rhel7.local:389} 5613a7ac0
nsds50ruv: {replica 1275 ldap://ipa003.mgmt.prod.local:389} 56797be
nsds50ruv: {replica 1390 ldap://ipa002.mgmt.paas.local:389} 5787bb9
nsds50ruv: {replica 1595 ldap://ipa002.mgmt.paas.local:389} 5787db0
nsds50ruv: {replica 1590 ldap://ipa003.mgmt.paas.local:389} 5787e0f



-- 
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] IPA certificates expired, please help!

2016-07-19 Thread Rob Crittenden 

Linov Suresh wrote:

I have followed Redhat official documentation,
https://access.redhat.com/solutions/643753 for certificate renewal,
which says *add: usercertificate. (step 12)*
*
*
While on the other hand FreeIPA official documentaion
http://www.freeipa.org/page/IPA_2x_Certificate_Renewal , say to *add:
usercertificate;binary*

Just wondering if we need to*add *the certificate? or*replace* the
existing certificate and which format do we need to use? *pem* or *der*.

We already successfully renewed the certificates about months back, but
they were expired about 6 months back and we were not able to renew till
now, and is affected our production environment.

Pleas help us.


You shouldn't have to mess with these values at all. In 3.0 this is 
handled somewhat automatically.


I'd restart the CA, then certmonger and see if the communication error 
goes away for the CA subservice certificates (the internal error).


# service pki-cad restart

# service certmonger restart

I find it very strange that the certificates were set to expire 
yesterday but it isn't a show-stopper necessarily assuming you can get 
the CA back up.


Assuming you can, then go back in time again, this time just a few days 
and try renewing the LDAP and Apache server certs again.


rob



On Tue, Jul 19, 2016 at 9:27 AM, Linov Suresh mailto:linov.sur...@gmail.com>> wrote:

We have cloned and created another virtual server from the template.
Surprisingly this server certificates were also expired at the same
time as the previous, just lasted for a day.
This issue has something to do with the kerberos tickets?

I am new to IPA and your help is highly appreciated.

On Mon, Jul 18, 2016 at 12:37 PM, Linov Suresh
mailto:linov.sur...@gmail.com>> wrote:

*Update: my webserver and LDAP certificates were expired at
2016-07-18 15:54:36 UTC and the certificates are in
CA_UNREACHABLE state.*
*
*
*Could you please help us?
*

[root@caer tmp]# getcert list
Number of certificates and requests being tracked: 8.
Request ID '20111214223243':
 status: CA_UNREACHABLE
 ca-error: Server failed request, will retry: -504
(libcurl failed to execute the HTTP POST transaction.  Peer
certificate cannot be authenticated with known CA certificates).
 stuck: yes
 key pair storage:

type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-TELOIP-NET//pwdfile.txt'
 certificate:

type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=TELOIP.NET

 subject: CN=caer.teloip.net
,O=TELOIP.NET 
*expires: 2016-07-18 15:54:36 UTC*
 eku: id-kp-serverAuth
 pre-save command:
 post-save command:
 track: yes
 auto-renew: yes
Request ID '20111214223300':
 status: CA_UNREACHABLE
 ca-error: Server failed request, will retry: -504
(libcurl failed to execute the HTTP POST transaction.  Peer
certificate cannot be authenticated with known CA certificates).
 stuck: yes
 key pair storage:

type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
 certificate:

type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=TELOIP.NET

 subject: CN=caer.teloip.net
,O=TELOIP.NET 
*expires: 2016-07-18 15:54:52 UTC*
 eku: id-kp-serverAuth
 pre-save command:
 post-save command:
 track: yes
 auto-renew: yes
Request ID '20111214223316':
 status: CA_UNREACHABLE
 ca-error: Server failed request, will retry: -504
(libcurl failed to execute the HTTP POST transaction.  Peer
certificate cannot be authenticated with known CA certificates).
 stuck: yes
 key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
 certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
 CA: IPA
 issuer: CN=Certificat

Re: [Freeipa-users] User Permissions Related Doubts

2016-07-19 Thread Rob Crittenden 

Zeal Vora wrote:

Hi!

I was planning to have a user who will have access to the below set of
permissions :-


1. kinit 
2. ipa host-add
3. ipa-host-add-managedby
4. ipa-getkeytab


I was wondering on what would be the minimum required permission for
this user? I was planning to use specific user other then the admin,

Any help will be appreciated!


I'd look at the Host Enrollment privilege to see if it does what you 
need. You might have to add Modify Hosts in order to add managedby (or 
create a similar privilege).


rob



--
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] IPA certificates expired, please help!

2016-07-19 Thread Linov Suresh 
I have followed Redhat official documentation,
https://access.redhat.com/solutions/643753 for certificate renewal, which
says *add: usercertificate. (step 12)*

While on the other hand FreeIPA official documentaion
http://www.freeipa.org/page/IPA_2x_Certificate_Renewal , say to *add:
usercertificate;binary*

Just wondering if we need to* add *the certificate? or* replace* the
existing certificate and which format do we need to use? *pem* or *der*.

We already successfully renewed the certificates about months back, but
they were expired about 6 months back and we were not able to renew till
now, and is affected our production environment.

Pleas help us.

On Tue, Jul 19, 2016 at 9:27 AM, Linov Suresh 
wrote:

> We have cloned and created another virtual server from the template.
> Surprisingly this server certificates were also expired at the same time as
> the previous, just lasted for a day.
> This issue has something to do with the kerberos tickets?
>
> I am new to IPA and your help is highly appreciated.
>
> On Mon, Jul 18, 2016 at 12:37 PM, Linov Suresh 
> wrote:
>
>> *Update: my webserver and LDAP certificates were expired at 2016-07-18
>> 15:54:36 UTC and the certificates are in CA_UNREACHABLE state.*
>>
>>
>> *Could you please help us? *
>>
>> [root@caer tmp]# getcert list
>> Number of certificates and requests being tracked: 8.
>> Request ID '20111214223243':
>> status: CA_UNREACHABLE
>> ca-error: Server failed request, will retry: -504 (libcurl failed
>> to execute the HTTP POST transaction.  Peer certificate cannot be
>> authenticated with known CA certificates).
>> stuck: yes
>> key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/dirsrv/slapd-TELOIP-NET//pwdfile.txt'
>> certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=TELOIP.NET
>> subject: CN=caer.teloip.net,O=TELOIP.NET
>>* expires: 2016-07-18 15:54:36 UTC*
>> eku: id-kp-serverAuth
>> pre-save command:
>> post-save command:
>> track: yes
>> auto-renew: yes
>> Request ID '20111214223300':
>> status: CA_UNREACHABLE
>> ca-error: Server failed request, will retry: -504 (libcurl failed
>> to execute the HTTP POST transaction.  Peer certificate cannot be
>> authenticated with known CA certificates).
>> stuck: yes
>> key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
>> certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=TELOIP.NET
>> subject: CN=caer.teloip.net,O=TELOIP.NET
>>* expires: 2016-07-18 15:54:52 UTC*
>> eku: id-kp-serverAuth
>> pre-save command:
>> post-save command:
>> track: yes
>> auto-renew: yes
>> Request ID '20111214223316':
>> status: CA_UNREACHABLE
>> ca-error: Server failed request, will retry: -504 (libcurl failed
>> to execute the HTTP POST transaction.  Peer certificate cannot be
>> authenticated with known CA certificates).
>> stuck: yes
>> key pair storage:
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>> certificate:
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=TELOIP.NET
>> subject: CN=caer.teloip.net,O=TELOIP.NET
>> *expires: 2016-07-18 15:55:04 UTC*
>> eku: id-kp-serverAuth
>> pre-save command:
>> post-save command:
>> track: yes
>> auto-renew: yes
>> Request ID '20130519130741':
>> status: MONITORING
>> ca-error: Internal error: no response to "
>> http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=61&renewal=true&xml=true
>> ".
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
>> certificate:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-renew-agent
>> issuer: CN=Certificate Authority,O=TELOIP.NET
>> subject: CN=CA Audit,O=TELOIP.NET
>> expires: 2017-10-13 14:10:49 UTC
>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>> "auditSigningCert cert-pki-ca"
>> track: yes
>>

Re: [Freeipa-users] AD trust with POSIX attributes

2016-07-19 Thread Jan Karásek 
Hi, 

I am still fighting with storing user's POSIX attributes in AD. Please can 
anybody provide some simple reference settings of IPA-AD trust where users are 
able to get uid from AD - not from IPA ID pool ? 

I have tried to set values of attributes before and after creating trust, I 
have tried different sssd setting but I'm still getting uid from IPA idrange 
pool instead of from AD user's attribute. 

What exactly is IPA checking when it tries to decide what type of trust will be 
set - ['ipa-ad-trust-posix', 'ipa-ad-trust'] ? 

Do I have to mandatory fill some AD user's attributes to get it work ? 
Currently I'am testing just with uidNumber and gidNumber. 

There is almost no documentation about this topic so I don't know what else I 
can try ... 

Thanks for help, 

Jan 



Date: Tue, 21 Jun 2016 21:38:15 +0200 
From: Jakub Hrozek  
To: freeipa-users@redhat.com 
Subject: Re: [Freeipa-users] AD trust with POSIX attributes 
Message-ID: <20160621193815.GS29512@hendrix> 
Content-Type: text/plain; charset=iso-8859-1 

On Tue, Jun 21, 2016 at 01:55:54PM +0200, Jan Kar?sek wrote: 
> Hi all, 
> 
> I have a questions about IPA with AD forest trust. What I am trying to do is 
> setup environment, where all informations about users are stored in one place 
> - AD. I would like to read at least uid, home, shell and sshkey from AD. 
> 
> I have set up trust with this parameters: 
> 
> ipa trust-add EXAMPLE.TT --type=ad --range-type=ipa-ad-trust-posix 
> --admin=administrator 

Did you add the POSIX attributes to AD after creating the trust maybe? 

> 
> [root@ipa1 ~]# ipa idrange-show EXAMPLE.TT_id_range 
> Range name: EXAMPLE.TT_id_range 
> First Posix ID of the range: 139200 
> Number of IDs in the range: 20 
> Domain SID of the trusted domain: S-1-5-21-4123312533-990676102-3576722756 
> Range type: Active Directory trust range with POSIX attributes 
> 
> 
> I have set attributes in AD for u...@example.tt 
> - uidNumber -1 
> - homeDirectory -/home/user 
> - loginShell - /bin/bash 
> 
> Trust itself works fine. I can do kinit with u...@example.tt , I can run id 
> and getent passwd u...@example.tt and I can use u...@example.tt for ssh. 
> 
> Problem is, that I am not getting uid from AD but from idrange: 
> 
> uid=1392001107(u...@example.tt) 
> 
> Also I have tried to switch off id mapping in sssd.conf with ldap_id_mapping 
> = true in sssd.conf but no luck. 

This has no effect, in IPA-AD trust scenario, the id mapping properties 
are managed on the server. 

> 
> I know, that it is probably better to use ID views for this, but in our case 
> we need to set centrally managed environment, where all users information are 
> externally inserted to AD from HR system - included POSIX attributes and we 
> need IPA to read them from AD. 

I think idviews are better for overriding POSIX attributes for a 
specific set of hosts, but in your environment, it sounds like you want 
to use the POSIX attributes across the board. 

> 
> So my questions are: 
> 
> Is it possible to read user's POSIX attributes directly from AD - namely uid 
> ? 

Yes 

> Which atributes can be stored in AD ? 

Homedir is a bit special, for backwards compatibility the 
subdomains_homedir takes precedence. The others should be read from AD. 

I don't have the environment set at the moment, though, so I'm operating 
purely from memory. 

> Am I doing something wrong ? 
> 
> my sssd.conf: 
> [domain/a.example.tt] 
> debug_level = 5 
> cache_credentials = True 
> krb5_store_password_if_offline = True 
> ipa_domain = a.example.tt 
> id_provider = ipa 
> auth_provider = ipa 
> access_provider = ipa 
> ipa_hostname = ipa1.a.example.tt 
> chpass_provider = ipa 
> ipa_server = ipa1.a.example.tt 
> ipa_server_mode = True 
> ldap_tls_cacert = /etc/ipa/ca.crt 
> #ldap_id_mapping = true 
> #subdomain_inherit = ldap_user_principal 
> #ldap_user_principal = nosuchattribute 
> 
> [sssd] 
> services = nss, sudo, pam, ssh 
> config_file_version = 2 
> 
> domains = a.example.tt 
> [nss] 
> debug_level = 5 
> homedir_substring = /home 
> enum_cache_timeout = 2 
> entry_negative_timeout = 2 
> 
> 
> [pam] 
> debug_level = 5 
> [sudo] 
> 
> [autofs] 
> 
> [ssh] 
> debug_level = 4 
> [pac] 
> 
> debug_level = 4 
> [ifp] 
> 
> Thanks, 
> Jan 





-- 
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] IPA certificates expired, please help!

2016-07-19 Thread Linov Suresh 
We have cloned and created another virtual server from the template.
Surprisingly this server certificates were also expired at the same time as
the previous, just lasted for a day.
This issue has something to do with the kerberos tickets?

I new to IPA and your help is highly appreciated.

On Mon, Jul 18, 2016 at 12:37 PM, Linov Suresh 
wrote:

> *Update: my webserver and LDAP certificates were expired at 2016-07-18
> 15:54:36 UTC and the certificates are in CA_UNREACHABLE state.*
>
>
> *Could you please help us? *
>
> [root@caer tmp]# getcert list
> Number of certificates and requests being tracked: 8.
> Request ID '20111214223243':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: -504 (libcurl failed
> to execute the HTTP POST transaction.  Peer certificate cannot be
> authenticated with known CA certificates).
> stuck: yes
> key pair storage:
> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/dirsrv/slapd-TELOIP-NET//pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=TELOIP.NET
> subject: CN=caer.teloip.net,O=TELOIP.NET
>* expires: 2016-07-18 15:54:36 UTC*
> eku: id-kp-serverAuth
> pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
> Request ID '20111214223300':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: -504 (libcurl failed
> to execute the HTTP POST transaction.  Peer certificate cannot be
> authenticated with known CA certificates).
> stuck: yes
> key pair storage:
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=TELOIP.NET
> subject: CN=caer.teloip.net,O=TELOIP.NET
>* expires: 2016-07-18 15:54:52 UTC*
> eku: id-kp-serverAuth
> pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
> Request ID '20111214223316':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: -504 (libcurl failed
> to execute the HTTP POST transaction.  Peer certificate cannot be
> authenticated with known CA certificates).
> stuck: yes
> key pair storage:
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=TELOIP.NET
> subject: CN=caer.teloip.net,O=TELOIP.NET
> *expires: 2016-07-18 15:55:04 UTC*
> eku: id-kp-serverAuth
> pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
> Request ID '20130519130741':
> status: MONITORING
> ca-error: Internal error: no response to "
> http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=61&renewal=true&xml=true
> ".
> stuck: no
> key pair storage:
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
> certificate:
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=TELOIP.NET
> subject: CN=CA Audit,O=TELOIP.NET
> expires: 2017-10-13 14:10:49 UTC
> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "auditSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130519130742':
> status: MONITORING
> ca-error: Internal error: no response to "
> http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=60&renewal=true&xml=true
> ".
> stuck: no
> key pair storage:
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
> certificate:
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=TELOIP.NET
> subject: CN=OCSP Subsystem,O=TELOIP.NET
> expires: 2017-10-13 14:09:49 UTC
> eku: id-kp-OCSPSigning
> pre-save command: /usr/lib64/ipa

Re: [Freeipa-users] OS migration from Fedora to CentOS?

2016-07-19 Thread Prashant Bapat 
I was in the exact same situation. Had to upgraded from FC21 (4.1.4) to
CentOS 7.2 (4.2.0). Upgrade went thru fine thanks to this thread :-)

For migrating the DNA ranges, I used this link
https://blog-rcritten.rhcloud.com/?p=50 Is this fine?

Thanks.

On 10 February 2016 at 15:02, Martin Kosek  wrote:

> On 02/05/2016 11:35 AM, Petr Vobornik wrote:
> > On 02/04/2016 06:14 PM, Christophe TREFOIS wrote:
> >> Hi all,
> >>
> >> We are currently running a 3-replica (all are setup with the —setup-ca
> flag)
> >> cluster on Fedora 21, with FreeIPA 4.1.4.
> >>
> >> We would like to slowly upgrade to the new version and move away from
> Fedora
> >> to CentOS 7.2.
> >>
> >> We were thinking of the following:
> >>
> >> - Create 3 CentOS machines with —setup-ca flag so that our current
> cluster is 6.
> >> The first CentOS VM would then probably update the DB schema to the new
> >> FreeIPA version.
> >> - Remove the Fedora VMs 1 by 1 from the cluster using
> ipa-replica-manage del
> >> 
> >> - Be happy?
> >>
> >>
> >> 1. Could you please advise if this is considered the safest practise?
> >
> > More or less yes:
> >
> > 1. create First IPA 4.2 against some FreeIPA 4.1.4 with CA
> > 2. create the other two against the newly Created CentOS - will verify
> if it is
> > in a good shape
> > 3. set new renewal CRL master:
> > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
> > 4. Migrate DNA ranges using ipa-replica-manage tool
> >
> > if all works well, remove all servers:
> >
> > 5. remove CA repl. agreements for old servers using ipa-csreplica-manage
> del
> > 6. remove old servers data and repl. agreements using ipa-replica-manage
> del
> > 7. uninstall old servers using ipa-server-install --uninstall
> >
> >> 2. Do we have to update to intermediate versions and if so how?
> >
> > Should not be necessary.
>
> Some advise is also present in the RHEL official docs:
>
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>
> --
> 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

[Freeipa-users] User Permissions Related Doubts

2016-07-19 Thread Zeal Vora 
Hi!

I was planning to have a user who will have access to the below set of
permissions :-


1. kinit 
2. ipa host-add
3. ipa-host-add-managedby
4. ipa-getkeytab


I was wondering on what would be the minimum required permission for this
user? I was planning to use specific user other then the admin,

Any help will be appreciated!


Thanks!
Zeal
-- 
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] non-authoritative tricks for DNS resolution

2016-07-19 Thread Petr Spacek 
On 18.7.2016 23:06, Brendan Kearney wrote:
> On 07/18/2016 06:12 AM, Petr Spacek wrote:
>> On 18.7.2016 03:25, Sullivan, Daniel [AAA] wrote:
>>> Would a DNS view (bind) work?
>>>
>>> http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm
>>>
>>> Also, depending on what you are using for NAT, some devices will mangle the
>>> reply payload of A record lookups as they traverse NAT to avoid haripinning
>>> (a packet going out and then back in the same interface as it traverses
>>> NAT).  This is known as DNS doctoring, at least in the world of Cisco.
>>>
>>> http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html
>>>
>>>
>>> Let me know if either of those will solve your problem.  If not, I might
>>> have a misunderstanding of what you are asking.
>>>
>>> Dan
>>>
 On Jul 17, 2016, at 3:36 PM, Brendan Kearney  wrote:

 i am looking to setup a VPN in order to access some resources, and want to
 point my clients at this resource via DNS.  the resource i am accessing is
 internet resolvable, but i am accessing it via the VPN, and using a NAT
 for the VPN (full 1-to-1 or static NAT).  i want to have a record in my
 DNS for this resource, using its proper name (which i am not authoritative
 for), but assign it the IP of my NAT.

 say for example, host.domain-ext.tld is the resource i want to access, and
 it resolves externally to 1.2.3.4.  my VPN NAT would be 192.168.99.137.  i
 want internal resolution of DNS to point to 192.168.99.137 so the network
 routing takes my internal clients to the VPN and not out to the internet.

 i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for
 dns.  how do i setup the zone and record to accomplish this DNS trick?  i
 have talked with some DNS gurus and they indicate that i can do something
 with the "@" record.  it seems that the record i want, would be its own
 zone, and the @ record would point to the name, and the SOA would be the
 NAT IP.  i could be wrong about the details, but something like this is
 how to setup resolution the way i want.

 any pointers would be greatly appreciated.
>> Background note:
>> All these DNS tricks are hacks to work around IP routing problem in
>> configuration you described.
>>
>> If you really want to use DNS tricks, you can create a DNS zone with name
>> equal to the you want to override and will this zone with A/ record at
>> zone apex (@).
>> The DNS approach has some inherent advantages:
>>
>> 1. All DNS names below the name you want to 'hijack' will not be resolvable 
>> in
>> your network. E.g. if the name is hijacked.example.com. then sub-domains like
>> anything.hijacked.example.com. will not be resolvable.
>>
>> 2. Your clients will go securely over VPN if and only if they use your local
>> DNS servers. Any client configured (even accidentally) to use some other DNS
>> server (e.g. public 8.8.8.8) will get the 'public' address and do not tunnel
>> the traffic over VPN.
>>
>>
>> Secure and reliable solution is not to use DNS but solve things on IP layer:
>> On the network gateway, configure IPSec tunnel (or any other VPN) in a way
>> that *the original IP address* is routed over VPN.
>>
>> This does not require any DNS tricks and thus will work regardless of client
>> configuration.
>>
>> I hope it helps.
>>
> our posture states that we do not route network space that is not ours, unless
> exigent circumstances dictate otherwise.  we have dedicated address space to
> NAT pools, in order to facilitate this. we also forbid external dns resolution
> from endpoints, by limiting what can go out to the roots for recursion. 

Blocking port 53 is slowly becoming a pointless exercise as RFC 7858 gets
incrementally adopted. DNS is going to be indistinguishable from any TLS
traffic, potentially even over port 443.

Having said that, it is better to plan for changes sooner than later.


> misconfigured clients are not able to perform DNS resolution.  we work with
> our counterparts on the other side of the VPN to ensure we are only adding a
> host record, and that sub-domains are not a point of failure for our access.
> 
> in terms of setting up this zone, how would one construct the ldif to create
> it?  because i am not using FreeIPA, i do not have the seemingly built-in
> tools to perform this function.  any reading material on the subject is 
> welcomed.

The zone would be the very same as any other DNS zone, please see
doc/example.ldif file in bind-dyndb-ldap distribution.

You want may play RPZ tricks but this needs to be done using standard BIND's
config.


Keep in mind that all this will break as soon as DNSSEC is enabled because
your address hijacking will be indistinguishable from an attack.

(In other words, this is the technically wrong approach. Solution on IP
routing layer is technically cleaner.)

-- 
Petr^2 Spacek

-- 
Manage your subscriptio

Re: [Freeipa-users] Unable to ssh after establishing trust

2016-07-19 Thread Sumit Bose 
On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
> 
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
> 
> /etc/hosts:
> Reachable_IP_BOX   172.10.10.1
> DC1172.10.10.1
> DC2172.10.10.1
> ...
> ...

The IP address should come first, please see man hosts for details.

> 
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'

Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?

> 
> 
> Additionally I have configured 
> [domain/ipa.internal]
>   with 
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
> 
> 
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting  extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.

Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.

bye,
Sumit

> 
> 
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
> 
> thanks
> ━━━
> From: Sumit Bose 
> To: pgb205 
> Cc: Sumit Bose ; Freeipa-users 
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> 
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> >  From: pgb205 
> >  To: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 2:12 PM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >   
> > Sumit, thanks for replying
> > So the first issue is my fault, probably from when I was sanitizing logs. 
> > our active directory domain is ad_domain.local, but users would expect to
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> > ewr-fipa_server used to be old trial server so I am not sure why it's still
> in the dns lookup results. I'll check this part further.
> > Lastly. only the connection to one of the domain controllers on AD side is
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf,
> a connection to this single, accessible domain controller. Are there any other
> files where I would needto lock down the connections between ipa->ad so that
> all traffic goes to specific active directory domain controller?
> > thanks again for replying so quickly.
> 
> Currently it is not possible to specify individual AD DC SSSD on the IPA
> server should talk to. We have ticket
> https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
> later versions of SSSD.
> 
> Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
> get a list of AD DC, then picks one to get the next nearest site for the
> IPA domain and finally tries to lookup a DC from the matching site (if
> any).
> 
> According to your logs SSSD was able to find 18 DCs with the SRV lookup.
> A call like
> 
> dig SRV _ldap._tcp.ad_domain.local
> 
> on the IPA server should return the same list of 18 DCs.
> 
> As a work-around, or better a hack, you might want to try to set the IP
> address of all the 18 DC returned to the IP address of the only
> accessible DC in /etc/hosts. This way SSSD should have no chance to
> connect to a different DC.
> 
> bye,
> 
> Sumit
> 
> >
> >  From: Sumit Bose 
> >  To: pgb205 
> > Cc: Sumit Bose 
> >  Sent: Tuesday, July 12, 2016 5:37 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> > 
> > On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > > Sumit, 
> > > sssd log files attached with debug=10 in all sections.I have attempted
> several logins for comparison as well as kinit commands
> >
> > I came across two issues in the logs.
> >
> > First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
> > but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the
> > AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently
> > FreeIPA cannot resolve those principals correctly. It was planned for
> > IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will
> > be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime
> > please try to work-around suggested at the end of
> > http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to
> > authenticate with user@AD