Re: [Freeipa-users] 32 bit netmask detection and error during install

2017-01-16 Thread Jeff Clay
I found where this had been fixed by
https://fedorahosted.org/freeipa/ticket/5814 and I have filed a bug report
requesting the patch to be backported
https://bugzilla.redhat.com/show_bug.cgi?id=1413742

On Mon, Jan 16, 2017 at 2:43 AM, David Kupka  wrote:

> On 16/01/17 03:15, Jeff Clay wrote:
>
>> I’m trying to install FreeIPA on CentOS 7. The server I’m using is a
>> Google Cloud Compute Engine instance. For some reason, they assign all
>> instances a /32 bit netmask on the internal interface even though you have
>> your own private /20 subnet.
>> When installing freeipa on these vm's, you get the error "Error: Invalid
>> IP Address 10.128.0.5: cannot use IP network address 10.128.0.5”
>>
>> Here are the settings for the interface.
>> eth0: flags=4163  mtu 1460
>> inet 10.128.0.5  netmask 255.255.255.255  broadcast 10.128.0.5
>> ether 42:01:0a:80:00:05  txqueuelen 1000  (Ethernet)
>> RX packets 17904  bytes 116212393 (110.8 MiB)
>> RX errors 0  dropped 0  overruns 0  frame 0
>> TX packets 19001  bytes 3287390 (3.1 MiB)
>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> How can I bypass that error and should /32 mask detection really be there?
>>
>> Thanks,
>>
>> Hello Jeff,
> this issue was already fixed upstream [1]. The fix is part of 4.4.2
> release. I'm afraid it's not available in CentOS yet. The easiest way would
> be to wait for the release to get to the CentOS or use Fedora instead.
>
> [1] https://fedorahosted.org/freeipa/ticket/5814
> --
> David Kupka
>
-- 
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] Windows Server can't use FreeIPA's DNS server

2017-01-16 Thread Raul Dias

Ok,

Found the issue.  I believe it is a Fedora (25) issue, but not sure 
yet.  So, registering here for the archives.


My IPA is on a FC25 on a LXC container (2.0.6) on a Jessie host.

The IPA container ethernet is on a private bridge (not attached to any 
real one).


The FC container was configured to do an offloading checksum.  I believe 
it was FC's fault, but could be some other lxc host on the same bridge, 
if possible.


Anyways, this command disabled offloading and it start to work:

# ethtool --offload eth0 rx off tx off gso off

Still, why only the 2k8 r2 complained about this, still have to be verified.

-rsd


--
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] Windows Server can't use FreeIPA's DNS server

2017-01-16 Thread Brian Candler

On 16/01/2017 16:37, Raul Dias wrote:

Did some testing.

From the windows server, did a port scanner on the IPA server (tcp + 
udp), no blocking between. (tested open).


The IPA has DNSSEC on, but that is for the zones only, right? There is 
no indication of DNSSEC in the datagrams.


You can have a DNSSEC-validating resolver (cache), but you're right 
you'd see things in the packet (EDNS).



The wireshark in the windows server:

Looks like a perfectly good DNS response to me.  Windows is a strange 
beast :-(


Horrible workaround: if you can find a DNS server which Windows likes, 
you can configure that DNS server to forward all the IPA-hosted zones to 
the IPA server.


--
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] Windows Server can't use FreeIPA's DNS server

2017-01-16 Thread Raul Dias

Did some testing.

From the windows server, did a port scanner on the IPA server (tcp + 
udp), no blocking between. (tested open).


The IPA has DNSSEC on, but that is for the zones only, right?  There is 
no indication of DNSSEC in the datagrams.


The wireshark in the windows server:

A - The query packet:
---
Ethernet II, Src: CadmusCo_58:90:cb (08:00:27:58:90:cb), Dst: 
fe:81:54:e3:7b:03 (fe:81:54:e3:7b:03)

Internet Protocol Version 4, Src: 10.10.24.12, Dst: 10.10.24.9
User Datagram Protocol, Src Port: 54680, Dst Port: 53
Domain Name System (query)
Transaction ID: 0x0006
Flags: 0x0100 Standard query
0...    = Response: Message is a query
.000 0...   = Opcode: Standard query (0)
 ..0.   = Truncated: Message is not truncated
 ...1   = Recursion desired: Do query recursively
  .0..  = Z: reserved (0)
  ...0  = Non-authenticated data: Unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
google.com: type A, class IN
Name: google.com
[Name Length: 10]
[Label Count: 2]
Type: A (Host Address) (1)
Class: IN (0x0001)

B - The response:
-

Frame 10: 222 bytes on wire (1776 bits), 222 bytes captured (1776 bits)
Ethernet II, Src: fe:81:54:e3:7b:03 (fe:81:54:e3:7b:03), Dst: 
CadmusCo_58:90:cb (08:00:27:58:90:cb)

Internet Protocol Version 4, Src: 10.10.24.9, Dst: 10.10.24.12
User Datagram Protocol, Src Port: 53, Dst Port: 54680
Domain Name System (response)
[Time: 0.057623000 seconds]
Transaction ID: 0x0006
Flags: 0x8180 Standard query response, No error
1...    = Response: Message is a response
.000 0...   = Opcode: Standard query (0)
 .0..   = Authoritative: Server is not an authority 
for domain

 ..0.   = Truncated: Message is not truncated
 ...1   = Recursion desired: Do query recursively
  1...  = Recursion available: Server can do 
recursive queries

  .0..  = Z: reserved (0)
  ..0.  = Answer authenticated: Answer/authority 
portion was not authenticated by the server

  ...0  = Non-authenticated data: Unacceptable
    = Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 4
Additional RRs: 4
Queries
google.com: type A, class IN
Name: google.com
[Name Length: 10]
[Label Count: 2]
Type: A (Host Address) (1)
Class: IN (0x0001)
Answers
google.com: type A, class IN, addr 216.58.222.14
Name: google.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 300
Data length: 4
Address: 216.58.222.14
Authoritative nameservers
google.com: type NS, class IN, ns ns4.google.com
Name: google.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 172792
Data length: 6
Name Server: ns4.google.com
google.com: type NS, class IN, ns ns1.google.com
Name: google.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 172792
Data length: 6
Name Server: ns1.google.com
google.com: type NS, class IN, ns ns3.google.com
Name: google.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 172792
Data length: 6
Name Server: ns3.google.com
google.com: type NS, class IN, ns ns2.google.com
Name: google.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 172792
Data length: 6
Name Server: ns2.google.com
Additional records
ns2.google.com: type A, class IN, addr 216.239.34.10
Name: ns2.google.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 172792
Data length: 4
Address: 216.239.34.10
ns1.google.com: type A, class IN, addr 216.239.32.10
Name: ns1.google.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 172792
Data length: 4
Address: 216.239.32.10
ns3.google.com: type A, class IN, addr 216.239.36.10
Name: ns3.google.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 172792
Data length: 4
Address: 216.239.36.10
ns4.google.com: type A, class IN, addr 216.239.38.10

[Freeipa-users] Managing AD Users in IPA

2017-01-16 Thread Denis Müller
Hi FreeIpa Community,

i'm actually new to the software and have some basic questions. We have linux 
users in in active directory.

To be more flexible, we would like to install freeipa, import all users from ad 
and manage all the stuff like ssh, sudo etc. from ipa.

1. Do i need establish a trust first like mentioned here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/creating-trusts.html#trust-one-two-way

2. Or can we just create a sync to import all "linux-users" from ad into ipa 
and manage them just like ipa-users:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/managing-sync-agmt.html

3. ipa-replica-manage connect --winsync --binddn  
cn=administrator,cn=users,dc=example,dc=com  --bindpw "***" --passsync "***" 
--cacert /root/dc1.crt dc1.example.com -v

getting an error:

Traceback (most recent call last):
  File "/usr/sbin/ipa-replica-manage", line 1607, in 
main(options, args)
  File "/usr/sbin/ipa-replica-manage", line 1566, in main
add_link(realm, replica1, replica2, dirman_passwd, options)
  File "/usr/sbin/ipa-replica-manage", line 1118, in add_link
if not ds.add_ca_cert(options.cacert):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 
1018, in add_ca_cert
certdb.load_cacert(cacert_fname, 'C,,')
  File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 261, 
in load_cacert
(rdn, subject_dn) = get_cert_nickname(cert)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 67, 
in get_cert_nickname
return (str(dn[0]), dn)
  File "/usr/lib/python2.7/site-packages/ipapython/dn.py", line 1170, in 
__getitem__
return self._get_rdn(self.rdns[key])
IndexError: list index out of range
Unexpected error: list index out of range

[root@ipa01 ~]# uname -r
3.10.0-327.el7.x86_64
[root@ipa01 ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

We would appreciate any help,

greets,
Denis
-- 
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] Switch certificates from external CA to internal

2017-01-16 Thread Florence Blanc-Renaud

On 01/12/2017 05:40 PM, Jeff Goddard wrote:

Thanks Flo,

My system is still in a bad state as I got this as a result of the command:

[root@id-management-1 ~]# ipa-cacert-manage renew --self-signed
Renewing CA certificate, please wait
Resubmitting certmonger request '20170101055025' timed out, please check
the request manually
The ipa-cacert-manage command failed.

The relevant output from getcert list was:
Request ID '20170101055025':
status: NEED_CSR_GEN_TOKEN
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=INTERNAL.EMERLYN.COM

subject: CN=localhost
expires: 2037-01-01 06:28:46 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
pre-save command:
post-save command:
track: yes
auto-renew: yes

I took the step of stopping tracking on that cert which was a mistake
and now I'm having a hard time with the syntax of adding it back.


Hi Jeff,

You would need the following to start-tracking the cert:
1. get the internal PIN
# grep 'internal=' /etc/pki/pki-tomcat/password.conf

2. monitor the cert
# getcert start-tracking -d /etc/pki/pki-tomcat/alias -n 'caSigningCert 
cert-pki-ca' -P  -c dogtag-ipa-ca-renew-agent -B 
/usr/libexec/ipa/certmonger/stop_pkicad -C 
'/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"'


HTH,
Flo.

Jeff







On Thu, Jan 12, 2017 at 10:46 AM, Florence Blanc-Renaud > wrote:

On 01/12/2017 02:57 PM, Jeff Goddard wrote:

I've had issues with expired certificates. In the course of
troubleshooting I've somehow set the cas to external. Is there a
way I
can switch back?

[root@id-management-1 conf]# getcert list-cas
CA 'SelfSign':
is-default: no
ca-type: INTERNAL:SELF
next-serial-number: 01
CA 'IPA':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-server-guard
/usr/libexec/certmonger/ipa-submit
CA 'certmaster':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/certmaster-submit
CA 'dogtag-ipa-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-server-guard
/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit
CA 'local':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/local-submit
CA 'dogtag-ipa-ca-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location:
/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit -vv

Thanks,

Jeff



Hi Jeff,

the following documentation explains how to change the certificate
chain from externally-signed to self-signed:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-cert-chaining.html



HTH,
Flo.







--
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] Error while issuing ipa-replica-install

2017-01-16 Thread Tomas Krizek
On 01/15/2017 05:58 PM, Carlos Silva wrote:
> In case someone stumbles in the message because it has the same
> problem, all the debugging and solution found is in this
> ticket: https://fedorahosted.org/freeipa/ticket/6613
>
>
You're hitting a known issue. We're currently working on a fix.

You can fix the problem yourself by modifying
/var/lib/pki/pki-tomcat/conf/server.xml on the master server. In the
AJP/1.3 Connector settings, change address from '::1' to 'localhost'.
After you restart the pki-tomcat service, you should be able to install
replicas.

-- 
Tomas Krizek

-- 
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] where is ipa cache?

2017-01-16 Thread Martin Basti

https://fedorahosted.org/sssd/wiki/Troubleshooting

Please try to troubleshoot using the page ^ above, it is weird that no 
communication between SSSD and server happened.


Martin


On 14.01.2017 13:39, Matrix wrote:

it should be.

you mean 'sss_cache -E' ? i have also tried to use to invalidate 
everything. sudo did not trigger any packets between client and server.


Matrix


-- Original --
*From: * "Fraser Tweedale";;
*Date: * Sat, Jan 14, 2017 07:29 PM
*To: * "Matrix";
*Cc: * "freeipa-users";
*Subject: * Re: [Freeipa-users] where is ipa cache?

On Sat, Jan 14, 2017 at 07:03:00PM +0800, Matrix wrote:
> Hi, all
>
>
> I have removed everything in /var/lib/sss/db. but sudo works fine.
>
>
> I have also tried to capture sudo search packets with tcpdump. I 
found that there is no packets transferred between ipa client and 
server. I am wondering where is ipa cache? in memory?

>
I think it is in memory.  Run `sss-cache -E' to dump the cache.

>
> Best Regards
>
>
> Matrix

> --
> 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] httpd broken

2017-01-16 Thread Martin Basti



On 15.01.2017 05:50, Gady Notrica wrote:


Hey guys,

After updating my IPA and http packages, httpd and samba are not 
starting. Something weird happening to the python code.


Any idea?

httpd.service - The Apache HTTP Server

Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; 
vendor preset: disabled)


Drop-In: /etc/systemd/system/httpd.service.d

└─ipa.conf

Active: failed (Result: exit-code) since Sat 2017-01-14 23:44:50 EST; 
33s ago


Docs: man:httpd(8)

man:apachectl(8)

Process: 3445 ExecStartPre=/usr/libexec/ipa/ipa-httpd-kdcproxy 
(code=exited, status=1/FAILURE)


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1643, in 
__wait_for_connection


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: 
wait_for_open_socket(lurl.hostport, timeout)


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: File 
"/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1286, in 
wait_for_open_socket


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: raise e



Hello, could you look into /var/log/httpd/error_log  and provide full 
stacktrace and related debug messages if any?


Martin
-- 
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] 32 bit netmask detection and error during install

2017-01-16 Thread David Kupka

On 16/01/17 03:15, Jeff Clay wrote:

I’m trying to install FreeIPA on CentOS 7. The server I’m using is a Google 
Cloud Compute Engine instance. For some reason, they assign all instances a /32 
bit netmask on the internal interface even though you have your own private /20 
subnet.
When installing freeipa on these vm's, you get the error "Error: Invalid IP 
Address 10.128.0.5: cannot use IP network address 10.128.0.5”

Here are the settings for the interface.
eth0: flags=4163  mtu 1460
inet 10.128.0.5  netmask 255.255.255.255  broadcast 10.128.0.5
ether 42:01:0a:80:00:05  txqueuelen 1000  (Ethernet)
RX packets 17904  bytes 116212393 (110.8 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 19001  bytes 3287390 (3.1 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

How can I bypass that error and should /32 mask detection really be there?

Thanks,


Hello Jeff,
this issue was already fixed upstream [1]. The fix is part of 4.4.2 
release. I'm afraid it's not available in CentOS yet. The easiest way 
would be to wait for the release to get to the CentOS or use Fedora instead.


[1] https://fedorahosted.org/freeipa/ticket/5814
--
David Kupka

--
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] Windows Server can't use FreeIPA's DNS server

2017-01-16 Thread Brian Candler

On 16/01/2017 00:52, Raul Dias wrote:

The  packets are getting back  That has being stablished already.


With Wireshark at the 2008R2 end?

I am looking for possible reasons it would disregard the answer, but 
accept when using a non-freeipa bind9 one.


Look at wireshark detail on both sets of responses; check for any 
differences including the flags. You're sure one of the servers isn't 
answering with a REFUSED answer for example? (That is, one of the bind 
servers might not allow queries from the source address of the 2008R2 
server)


Also compare the bind configs. For example, is DNSSEC enabled in one but 
not the other?


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