[Freeipa-users] ipa replica installation help

2017-01-03 Thread Ben .T.George
HI

while trying to create ipa replica, i am getting below error,

Replica creation using 'ipa-replica-prepare' to generate replica file
is supported only in 0-level IPA domain.

The current IPA domain level is 1 and thus the replica must
be created by promoting an existing IPA client.

To set up a replica use the following procedure:
1.) set up a client on the host using 'ipa-client-install'
2.) promote the client to replica running 'ipa-replica-install'
*without* replica file specified

'ipa-replica-prepare' is allowed only in domain level 0
The ipa-replica-prepare command failed.


i have IPA master server without AD integration and DNS is managed by 3rd
party appliances.



Regards,
Ben
-- 
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] Topology -> IPA Servers

2017-01-03 Thread Ian Harding
I have finally had some luck expunging the remnants of long removed IPA
servers now that I have upgraded to FreeIPA 4.4.

However, when I look at the IPA Servers list under Topology, I now have
three records like so:


Server name Min domain level Max domain level Managed suffixes

freeipa-dal.bpt.rocks
freeipa-sea.bpt.rocks 0 1 domain, ca
seattlenfs.bpt.rocks 0 0 domain
Showing 1 to 3 of 3 entries.

And an error dialog pops up which says "freeipa-dal.bpt.rocks: server
not found" which is true, it's long dead.

[root@freeipa-sea ianh]# ipa-replica-manage del --force --cleanup
freeipa-dal.bpt.rocks
Cleaning a master is irreversible.
This should not normally be require, so use cautiously.
Continue to clean master? [no]: yes

[root@freeipa-sea ianh]# ipa host-find freeipa-dal.bpt.rocks --all
---
0 hosts matched
---

Number of entries returned 0

[root@freeipa-sea ianh]# ipa-replica-manage list
seattlenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: master
freeipa-sea.bpt.rocks: master
[root@freeipa-sea ianh]# ipa-replica-manage list-ruv
Directory Manager password:

Replica Update Vectors:
seattlenfs.bpt.rocks:389: 21
freeipa-sea.bpt.rocks:389: 20
Certificate Server Replica Update Vectors:
freeipa-sea.bpt.rocks:389: 1065

Any ideas how to make that ghost finally go away?  I'm trying to change
the domain level of freeipa-sea.bpt.rocks, but when I do I get

"Domain Level cannot be raised to 1, server freeipa-dal.bpt.rocks does
not support it."

Thanks!
-- 
Ian Harding
IT Director
Brown Paper Tickets
1-800-838-3006 ext 7186
http://www.brownpapertickets.com

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


Re: [Freeipa-users] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

2017-01-03 Thread Alan Latteri
Well on new installs of Cent 7.2, when I do `yum install ipa-client`, that is 
the version provided.
Unfortunately, most of our systems have to be on Cent 7.2, not 7.3, and it is 
out of our control.

Alan

> On Jan 3, 2017, at 8:33 PM, Rob Crittenden  wrote:
> 
> Alan Latteri wrote:
>> Further investigation.
>> 
>> On a clean install of CentOS 7.2 with IPA Client 4.4, /etc/krb5.conf.d/ is 
>> missing, and therefore initial setup will fail unless manual creation of 
>> /etc/krb5.conf.d/
>> Maybe the install script for the client can be updated to check for and 
>> create?
> 
> Is there a reason you're running 7.3 packages on a 7.2 system? I suspect
> that is the problem. AFAIU in 7.3 this directory is provided by krb5-libs.
> 
> Is there some feature you need in the 4.4 client installer on 7.2?
> 
> rob
> 
>> 
>> Thanks,
>> Alan
>> 
>>> On Jan 3, 2017, at 1:44 PM, Alan Latteri  
>>> wrote:
>>> 
>>> Thanks Rob.
>>> 
>>> /etc/krb5.conf.d/  was in fact missing from the client, which is still on 
>>> CentOS 7.2 for reasons out of our control.
>>> Other hosts that are CentOS 7.2 running IPA Client 4.2.0 also do not have 
>>> the /etc/krb5.conf.d/ directory, but are running fine.  So maybe the 4.4 
>>> client requires that dir but is not making it on upgrade and the cause of 
>>> the failure?
>>> 
>>> Alan
>>> 
 On Jan 3, 2017, at 1:25 PM, Rob Crittenden  wrote:
 
 Alan Latteri wrote:
> Log is attached.
 
 Look and see if /etc/krb5.conf.d/ and
 /var/lib/sss/pubconf/krb5.include.d exist and are readable (and check
 for SELinux AVCs). I'm pretty sure this all runs as root so I doubt
 filesystem perms are an issue but who knows.
 
 You can also brute force things using strace -f to find out exactly what
 can't be read.
 
 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
>> 
> 


-- 
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] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

2017-01-03 Thread Alan Latteri
Further investigation.

On a clean install of CentOS 7.2 with IPA Client 4.4, /etc/krb5.conf.d/ is 
missing, and therefore initial setup will fail unless manual creation of 
/etc/krb5.conf.d/
Maybe the install script for the client can be updated to check for and create?

Thanks,
Alan

> On Jan 3, 2017, at 1:44 PM, Alan Latteri  wrote:
> 
> Thanks Rob.
> 
> /etc/krb5.conf.d/  was in fact missing from the client, which is still on 
> CentOS 7.2 for reasons out of our control.
> Other hosts that are CentOS 7.2 running IPA Client 4.2.0 also do not have the 
> /etc/krb5.conf.d/ directory, but are running fine.  So maybe the 4.4 client 
> requires that dir but is not making it on upgrade and the cause of the 
> failure?
> 
> Alan
> 
>> On Jan 3, 2017, at 1:25 PM, Rob Crittenden  wrote:
>> 
>> Alan Latteri wrote:
>>> Log is attached.
>> 
>> Look and see if /etc/krb5.conf.d/ and
>> /var/lib/sss/pubconf/krb5.include.d exist and are readable (and check
>> for SELinux AVCs). I'm pretty sure this all runs as root so I doubt
>> filesystem perms are an issue but who knows.
>> 
>> You can also brute force things using strace -f to find out exactly what
>> can't be read.
>> 
>> 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


-- 
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 resolve AD users from IPA clients

2017-01-03 Thread Jakub Hrozek
On Tue, Jan 03, 2017 at 03:39:19PM +0100, Jan Karásek wrote:
> Hi, 
> 
> I have trouble with resolving AD users from my IPA clients. 
> 
> Environment: 2x IPA server with trust into AD - both IPA servers and clients 
> running latest rhel 7.3. 
> 
> IPA domain: vs.example.com 
> AD domain: example.com, cen.example.com 
> 
> All tstx users are in cen.example.com but their UPN is set to 
> tstxx...@example.com 
> 
> I can run id and getent passwd commands without problem from both IPA 
> servers: 
> 
> id tst99...@example.com 
> uid=20018(tst99...@cen.example.com) gid=5001(csunix) 
> groups=5001(csunix),93008(final_test_group) 
> 
> getent tst99...@example.com 
> tst99...@cen.example.com:*:20018:5001:ipa_test:/home/cen.example.com/tst99655:/bin/bash
>  
> 
> But from client: 
> 
> root@trh7clnt02:~# id tst99...@example.com 
> id: tst99...@example.com: no such user 
> root@trh7clnt02:~#getent passwd tst99...@example.com 
> ... no reply 
> 
> 
> But when I run on client: 
> getent group csu...@cen.example.com - it takes more then 30s 
> csu...@cen.example.com:*:5001:  and really long list of users 
> 
> Then again from client: 
> 
> root@trh7clnt02:~# id tst99...@example.com 
> uid=20018(tst99...@cen.example.com) gid=5001(csunix) groups=5001(csunix) 
> 
> root@trh7clnt02:~# getent passwd tst99...@example.com 
> tst99...@cen.example.com:*:20018:5001:ipatest:/home/cen.example.com/tst99655:/bin/bash
>  
> 
> This time it works and it keeps working until I clean the sssd cache on 
> client. Then I have to run that getent group csunix command again. 
> 
> I would say it is some timeout issue with enumerating csunix group. I have 
> tried to fix it by adding: 
> 
> ldap_search_timeout = 50 

I don't think this would be related to the searches timing out but
probably parsing and storing the entries on the server and the client.

Could you try adding this on the server side's sssd.conf?

[domain/domname]
subdomain_inherit = ignore_group_members
ignore_group_members = True

By the way, did you install 7.3 cleanly or did you upgrade? And if you
upgraded, did you ever removed the cache post-upgrade on the server?

There's been some improvements related to performance in 7.3 and even
more are coming in 7.4.

-- 
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] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

2017-01-03 Thread Alan Latteri
Thanks Rob.

/etc/krb5.conf.d/  was in fact missing from the client, which is still on 
CentOS 7.2 for reasons out of our control.
Other hosts that are CentOS 7.2 running IPA Client 4.2.0 also do not have the 
/etc/krb5.conf.d/ directory, but are running fine.  So maybe the 4.4 client 
requires that dir but is not making it on upgrade and the cause of the failure?

Alan

> On Jan 3, 2017, at 1:25 PM, Rob Crittenden  wrote:
> 
> Alan Latteri wrote:
>> Log is attached.
> 
> Look and see if /etc/krb5.conf.d/ and
> /var/lib/sss/pubconf/krb5.include.d exist and are readable (and check
> for SELinux AVCs). I'm pretty sure this all runs as root so I doubt
> filesystem perms are an issue but who knows.
> 
> You can also brute force things using strace -f to find out exactly what
> can't be read.
> 
> 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] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

2017-01-03 Thread Rob Crittenden
Alan Latteri wrote:
> Log is attached.

Look and see if /etc/krb5.conf.d/ and
/var/lib/sss/pubconf/krb5.include.d exist and are readable (and check
for SELinux AVCs). I'm pretty sure this all runs as root so I doubt
filesystem perms are an issue but who knows.

You can also brute force things using strace -f to find out exactly what
can't be read.

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] ldap_rename: Operations error (1)

2017-01-03 Thread Dan.Finkelstein
I'm running FreeIPA 4.4.0 on CentOS 7.3 and I almost succeeded in renaming a 
duplicate, but then this happens:

modifying rdn of entry 
"cn=ipaservers+nsuniqueid=9865b29e-c9a411e6-a937f721-75eb0f97,cn=hostgroups,cn=accounts,dc=test,dc=local"
ldap_rename: Operations error (1)

The commands were:
$ ldapmodify -D "cn=directory manager" -W -p 389 -h ipa.test.local -x
Enter LDAP Password:
dn: 
cn=ipaservers+nsuniqueid=9865b29e-c9a411e6-a937f721-75eb0f97,cn=hostgroups,cn=accounts,dc=test,dc=local
changetype: modrdn
newrdn: cn=9865b29e
deleteoldrdn: 0

Any ideas?

[id:image001.jpg@01D1C26F.0E28FA60]
Daniel Alex Finkelstein| Lead Dev Ops Engineer
dan.finkelst...@h5g.com | 212.604.3447
One World Trade Center, New York, NY 10007

www.high5games.com
Play High 5 Casino and Shake the 
Sky
Follow us on: Facebook, 
Twitter, 
YouTube, 
Linkedin

This message and any attachments may contain confidential or privileged 
information and are only for the use of the intended recipient of this message. 
If you are not the intended recipient, please notify the sender by return 
email, and delete or destroy this and all copies of this message and all 
attachments. Any unauthorized disclosure, use, distribution, or reproduction of 
this message or any attachments is prohibited and may be unlawful.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 2FA and AllowNTHash

2017-01-03 Thread Brian Candler

On 03/01/2017 15:28, Maciej Drobniuch wrote:

We have a topo with 3x IPA servers + freeradius.

Freeradius is being used to do mschap with wifi APs. Freeradius 
connects over ldap to IPA.


In order to do the challange-response thing, freeipa has AllowNTHash 
enabled.


So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth.

In the moment I disallow Password auth for a user and enable OTP the 
wifi auth stopps working, but the hash clearly stays in ldap.
How are you actually authenticating the user? Are you just reading the 
ipaNTHash out of the LDAP database and letting FreeRADIUS check it? Then 
AFAICS it shouldn't make any different whether OTP is enabled or not.  
Can you show more of your RADIUS config, and the debug output from the 
part which authenticates the user?


I don't use OTP myself, but I wouldn't expect the ipaNTHash to change 
depending on whether OTP is enabled or not (and you're saying the hash 
stays put).


I have what sounds like a similar setup to yours, using FreeRADIUS 
3.0.12 talking to FreeIPA 4.4.0, using a service user which has 
permissions to read out the ipaNTHash directly, based on this blog post:

http://firstyear.id.au/blog/html/2015/07/06/FreeIPA:_Giving_permissions_to_service_accounts..html

ldap config:

base_dn = 'cn=users,cn=accounts,dc=ipa,dc=example,dc=com'

sasl {
mech = 'GSSAPI'
realm = 'IPA.EXAMPLE.COM'
}

update {
control:NT-Password := 'ipaNTHash'
control:Tmp-String-9:= 'krbPasswordExpiration'
}

user {
base_dn = "${..base_dn}"
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
scope = "one"
}

group {
membership_attribute = 'memberOf'
name_attributes = 'cn'

cacheable_dn = 'yes'
cacheable_name = 'no'
}

default and inner-tunnel authentication is then just:

authenticate {
Auth-Type PAP {
pap
}

Auth-Type MS-CHAP {
mschap
}

eap
}

Also you need to put the service user's keytab somewhere, and set a 
couple of environment variables when it starts, if you want to use 
Kerberos to protect the LDAP connection. Using systemd override:


[Unit]
Requires=dirsrv.target
After=dirsrv.target

[Service]
Environment=KRB5_CLIENT_KTNAME=/etc/radiusd.keytab
Environment=KRB5CCNAME=MEMORY:
Restart=always
RestartSec=5

(Otherwise you can bind with a specific dn and password, but then you 
also need to sort out TLS to secure the LDAP traffic)


There is more magic you can do with the krbPasswordExpiration attribute 
to force the user to do a password change over MSCHAP - but that's now 
straying a long way from what's relevant on a FreeIPA mailing list.


HTH,

Brian.

--
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] Minimum SSSD version for 2 factor

2017-01-03 Thread Lukas Slebodnik
On (03/01/17 10:15), Sean Hogan wrote:
>
>Morning,
>
>   Hope the Holidays went well for you all.
>
>   I have been trying to find documentation on the required min sssd
>version needed to run otp (2 factor) with no luck.  Was hoping you all
>might know.
>I see RHEL 6.8 comes with 1.13 SSSD so was wondering if that would be high
>enough version to work with IPA 4.X OTP.
>
sssd 1.13 could handle OTP but there is old MIT krb5
and therefore sssd is compiled without OTP feature in rhel6

LS

-- 
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] how to make email as mandatory field before user creation

2017-01-03 Thread Petr Vobornik
On 01/02/2017 08:46 PM, nirajkumar.si...@accenture.com wrote:
> Hi Prtr,
> 
> Can you please suggest how to do it with plugins and which plugin I need to 
> use and how to integrate that plugin with freeipa.
> 
> Thanks
> Niraj

Disclaimer: the example below is not really save because it doesn't
handle e.g. stageusers and it might not work with later releases of
FreeIPA because IPA doesn't provide any supported plugin API yet.

Example: https://pvoborni.fedorapeople.org/plugins/backend/zuserplugin.py

Old(FreeIPA 3.3) extending guide:
  http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf

> 
> -Original Message-
> From: Petr Vobornik [mailto:pvobo...@redhat.com]
> Sent: 02 January 2017 22:21
> To: Singh, NirajKumar ; 
> freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] how to make email as mandatory field before user 
> creation
> 
> On 01/02/2017 05:00 PM, nirajkumar.si...@accenture.com wrote:
>> Hi Team,
>>
>> Is there any way to make email as mandatory field before creating any
>> user from WEBUI or Console?
>>
>> Thanks & Regards,
>>
>> Niraj Kumar Singh
>>
> 
> Hello Niraj,
> 
> FreeIPA doesn't support such configuration out of the box.
> 
> It is theoretically possible to implement IPA server side plugin to mark the 
> field as required. It may not be straightforward though.
> 
> --
> Petr Vobornik
> 
> 
> 
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise confidential information. If you have received it 
> in error, please notify the sender immediately and delete the original. Any 
> other use of the e-mail by you is prohibited. Where allowed by local law, 
> electronic communications with Accenture and its affiliates, including e-mail 
> and instant messaging (including content), may be scanned by our systems for 
> the purposes of information security and assessment of internal compliance 
> with Accenture policy.
> __
> 
> www.accenture.com
> 


-- 
Petr Vobornik

-- 
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] Minimum SSSD version for 2 factor

2017-01-03 Thread Jochen Hein
"Sean Hogan"  writes:

>I have been trying to find documentation on the required min sssd
> version needed to run otp (2 factor) with no luck.  Was hoping you all
> might know.
> I see RHEL 6.8 comes with 1.13 SSSD so was wondering if that would be high
> enough version to work with IPA 4.X OTP.

I'm running 2FA/OTP on Ubuntu 14.04 with the following sssd:
ii  sssd 1.12.5-1~trusty1i386
System Security Services Daemon -- metapackage

What you miss is the prompt "First Factor"/"Second Factor" and you must
concatenate password and OTP at the password prompt. Otherwise it works
fine.

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] Minimum SSSD version for 2 factor

2017-01-03 Thread Sean Hogan

Disregard... apparently I am blind.   Min is 1.12 per IPA docs.




Sean Hogan









From:   Sean Hogan/Durham/IBM
To: freeipa-users 
Date:   01/03/2017 10:15 AM
Subject:Minimum SSSD version for 2 factor


Morning,

   Hope the Holidays went well for you all.

   I have been trying to find documentation on the required min sssd
version needed to run otp (2 factor) with no luck.  Was hoping you all
might know.
I see RHEL 6.8 comes with 1.13 SSSD so was wondering if that would be high
enough version to work with IPA 4.X OTP.




Thank You
Sean Hogan







-- 
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] Minimum SSSD version for 2 factor

2017-01-03 Thread Sean Hogan

Morning,

   Hope the Holidays went well for you all.

   I have been trying to find documentation on the required min sssd
version needed to run otp (2 factor) with no luck.  Was hoping you all
might know.
I see RHEL 6.8 comes with 1.13 SSSD so was wondering if that would be high
enough version to work with IPA 4.X OTP.




Thank You
Sean Hogan






-- 
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] FIPS 140-2 Compliance

2017-01-03 Thread Petr Vobornik
On 01/03/2017 04:28 PM, Sean Conley wrote:
> Good Morning!
> 
> Happy New Year to you, and any news on getting to FIPS Compliance?
> 
> *Michael Sean Conley*
> 
> Principal Systems Engineer
> 
> 
> 

Hello Sean,

It's being actively developed and support of it will most likely be part
of FreeIPA 4.5.
-- 
Petr Vobornik

-- 
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] os-x sierra + FreeIPA

2017-01-03 Thread Grant Janssen
I am experiencing difficulty dragging this over the finish line.  I have many 
CentOS hosts authenticating to IPA, but have hit the wall on OS-X.
I consider myself pretty strong on os-x, and have run OpenDirectory (though 
that was ten years ago). My issue appears to be the LDAP mapping between OD and 
IPA.
System Intregrity Protection is disabled.  Users can pull tickets fine, this 
snag is in login/createhomedir.

I initially posted this on the bug list, and was redirected here.
You will find the details of this issue easiest to digest on the bug 
list (wiki markup is better that 
what this maling list would retain).

Please take a glance and let me know what you think.

Thank You for your attention.

- grant
This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] LDAP - Load Balancer - SSL cert with SAN

2017-01-03 Thread Maciej Drobniuch
I see.

Generally the SAN thing I mentioned does the job but definitely not in your
case.

A IPA power user is needed here.

On Tue, Jan 3, 2017 at 4:26 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

> Maciej,
>   Thank you for the information.  I am not terminating at a load
> balancer.  Originally, I was trying to use a Route53 DNS CNAME entry of
> ipa.dev.crosschx.com but we found documentation that says the entry
> should be an A record and not a CNAME.  I then created an A record in
> FreeIPA for ipa.dev.crosschx.com and pointed the A record to the IP
> addresses of ipa-master.dev.crosschx.com and ipa-replica.dev.crosschx.com.
>
>   I guess using the phrase load balancer may be a poor choice here as I am
> using FreeIPA DNS as a way to load balance the traffic.
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614-741-5475 <(614)%20741-5475>
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Tue, Jan 3, 2017 at 10:14 AM, Maciej Drobniuch  > wrote:
>
>> Hello Mike,
>>
>> I don't know if I'm aligned with your problem, but generally I was facing
>> a SAN cert issue too.
>>
>> Not sure if you're terminating SSL/TLS on the load balancer or not?
>>
>> Usually I do SAN certs in IPA via GUI/IdM.
>> I am adding a service and hosts assigned to that service.
>>
>> Every host has an additional https service.
>>
>> Then I am simply pasting the SAN csr into the host that owns the main
>> service and this creates a signed SAN cert that you can upload later to
>> your LB.
>>
>> In simple words the service is assigned to all hosts but those hosts have
>> also a service added(this is a hack).
>>
>> Hope that makes sense and helps solving your problem.
>>
>> BR
>>
>> On Thu, Dec 29, 2016 at 10:48 PM, Michael Plemmons <
>> michael.plemm...@crosschx.com> wrote:
>>
>>> I am trying to get FreeIPA LDAP to work when behind a load balancer and
>>> using SSL and I do not understand how I am supposed to get the server to
>>> use a certificate I created that has a SAN created.
>>>
>>> FreeIPA 4.4.0 on CentOS 7
>>>
>>> Here is what I have:
>>> ipa-master.dev.crosschx.com - master
>>> ipa-replica.dev.crosschx.com - replica
>>> ipa.dev.crosschx.com - load balancer DNS name which point to the master
>>> and replica servers
>>>
>>> Here is what I have done.
>>> ipa host-add ipa.dev.crosschx.com --random --force
>>>
>>> ipa service-add --force ldap/ipa.dev.crosschx.com
>>>
>>> ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={
>>> ipa-master.dev.crosschx.com,ipa-replica.dev.crosschx.com}
>>>
>>> ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com
>>> --users=admin
>>>
>>> ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN=
>>> ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com
>>> -K ldap/ipa-master.dev.crosschx.com
>>>
>>>
>>> I can see the certificate is being monitored by IPA when I run
>>> ipa-getcert list but I am lost at the step to have this cert put into the
>>> database so that IPA will properly respond when I try to connect over LDAPS.
>>>
>>> I was testing the connection with the following command and I see the
>>> the ipa-master.dev cert being served.
>>>
>>> openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername
>>> ipa.dev.crosschx.com
>>>
>>> Can you point me to the documentation I need to follow?
>>>
>>> Thank you.
>>>
>>>
>>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
>>> 614-741-5475 <(614)%20741-5475>
>>> mike.plemm...@crosschx.com
>>> www.crosschx.com
>>>
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> Go to http://freeipa.org for more info on the project
>>>
>>
>>
>>
>> --
>> Best regards
>>
>> Maciej Drobniuch
>> Network Security Engineer
>> Collective-Sense,LLC
>>
>
>


-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] FIPS 140-2 Compliance

2017-01-03 Thread Sean Conley
Good Morning!
Happy New Year to you, and any news on getting to FIPS Compliance?

Michael Sean Conley
Principal Systems Engineer

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

[Freeipa-users] 2FA and AllowNTHash

2017-01-03 Thread Maciej Drobniuch
Hi All,

We have a topo with 3x IPA servers + freeradius.

Freeradius is being used to do mschap with wifi APs. Freeradius connects
over ldap to IPA.

In order to do the challange-response thing, freeipa has AllowNTHash
enabled.

So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth.

In the moment I disallow Password auth for a user and enable OTP the wifi
auth stopps working, but the hash clearly stays in ldap.

The goal is to stay with password on freeradius but for everything else:
kerberos/sssd related use password+code.

How can I disable password login for user but still make freeradius work
with ldap, so when it asks for users hash it gets one.

Freeradius ldap mod snippet:
"base_dn = "cn=users,cn=accounts,dc=cs,dc=com""

Thank You

-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] LDAP - Load Balancer - SSL cert with SAN

2017-01-03 Thread Michael Plemmons
Maciej,
  Thank you for the information.  I am not terminating at a load balancer.
Originally, I was trying to use a Route53 DNS CNAME entry of
ipa.dev.crosschx.com but we found documentation that says the entry should
be an A record and not a CNAME.  I then created an A record in FreeIPA for
ipa.dev.crosschx.com and pointed the A record to the IP addresses of
ipa-master.dev.crosschx.com and ipa-replica.dev.crosschx.com.

  I guess using the phrase load balancer may be a poor choice here as I am
using FreeIPA DNS as a way to load balance the traffic.




*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614-741-5475
mike.plemm...@crosschx.com
www.crosschx.com

On Tue, Jan 3, 2017 at 10:14 AM, Maciej Drobniuch 
wrote:

> Hello Mike,
>
> I don't know if I'm aligned with your problem, but generally I was facing
> a SAN cert issue too.
>
> Not sure if you're terminating SSL/TLS on the load balancer or not?
>
> Usually I do SAN certs in IPA via GUI/IdM.
> I am adding a service and hosts assigned to that service.
>
> Every host has an additional https service.
>
> Then I am simply pasting the SAN csr into the host that owns the main
> service and this creates a signed SAN cert that you can upload later to
> your LB.
>
> In simple words the service is assigned to all hosts but those hosts have
> also a service added(this is a hack).
>
> Hope that makes sense and helps solving your problem.
>
> BR
>
> On Thu, Dec 29, 2016 at 10:48 PM, Michael Plemmons <
> michael.plemm...@crosschx.com> wrote:
>
>> I am trying to get FreeIPA LDAP to work when behind a load balancer and
>> using SSL and I do not understand how I am supposed to get the server to
>> use a certificate I created that has a SAN created.
>>
>> FreeIPA 4.4.0 on CentOS 7
>>
>> Here is what I have:
>> ipa-master.dev.crosschx.com - master
>> ipa-replica.dev.crosschx.com - replica
>> ipa.dev.crosschx.com - load balancer DNS name which point to the master
>> and replica servers
>>
>> Here is what I have done.
>> ipa host-add ipa.dev.crosschx.com --random --force
>>
>> ipa service-add --force ldap/ipa.dev.crosschx.com
>>
>> ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={
>> ipa-master.dev.crosschx.com,ipa-replica.dev.crosschx.com}
>>
>> ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com --users=admin
>>
>> ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN=
>> ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com
>> -K ldap/ipa-master.dev.crosschx.com
>>
>>
>> I can see the certificate is being monitored by IPA when I run
>> ipa-getcert list but I am lost at the step to have this cert put into the
>> database so that IPA will properly respond when I try to connect over LDAPS.
>>
>> I was testing the connection with the following command and I see the the
>> ipa-master.dev cert being served.
>>
>> openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername
>> ipa.dev.crosschx.com
>>
>> Can you point me to the documentation I need to follow?
>>
>> Thank you.
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
>> 614-741-5475 <(614)%20741-5475>
>> mike.plemm...@crosschx.com
>> www.crosschx.com
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
>
> --
> Best regards
>
> Maciej Drobniuch
> Network Security Engineer
> Collective-Sense,LLC
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] LDAP - Load Balancer - SSL cert with SAN

2017-01-03 Thread Maciej Drobniuch
Hello Mike,

I don't know if I'm aligned with your problem, but generally I was facing a
SAN cert issue too.

Not sure if you're terminating SSL/TLS on the load balancer or not?

Usually I do SAN certs in IPA via GUI/IdM.
I am adding a service and hosts assigned to that service.

Every host has an additional https service.

Then I am simply pasting the SAN csr into the host that owns the main
service and this creates a signed SAN cert that you can upload later to
your LB.

In simple words the service is assigned to all hosts but those hosts have
also a service added(this is a hack).

Hope that makes sense and helps solving your problem.

BR

On Thu, Dec 29, 2016 at 10:48 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

> I am trying to get FreeIPA LDAP to work when behind a load balancer and
> using SSL and I do not understand how I am supposed to get the server to
> use a certificate I created that has a SAN created.
>
> FreeIPA 4.4.0 on CentOS 7
>
> Here is what I have:
> ipa-master.dev.crosschx.com - master
> ipa-replica.dev.crosschx.com - replica
> ipa.dev.crosschx.com - load balancer DNS name which point to the master
> and replica servers
>
> Here is what I have done.
> ipa host-add ipa.dev.crosschx.com --random --force
>
> ipa service-add --force ldap/ipa.dev.crosschx.com
>
> ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={ipa-master.dev.
> crosschx.com,ipa-replica.dev.crosschx.com}
>
> ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com --users=admin
>
> ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN=
> ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com
> -K ldap/ipa-master.dev.crosschx.com
>
>
> I can see the certificate is being monitored by IPA when I run ipa-getcert
> list but I am lost at the step to have this cert put into the database so
> that IPA will properly respond when I try to connect over LDAPS.
>
> I was testing the connection with the following command and I see the the
> ipa-master.dev cert being served.
>
> openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername
> ipa.dev.crosschx.com
>
> Can you point me to the documentation I need to follow?
>
> Thank you.
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614-741-5475 <(614)%20741-5475>
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>



-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Unable to resolve AD users from IPA clients

2017-01-03 Thread Jan Karásek
Hi, 

I have trouble with resolving AD users from my IPA clients. 

Environment: 2x IPA server with trust into AD - both IPA servers and clients 
running latest rhel 7.3. 

IPA domain: vs.example.com 
AD domain: example.com, cen.example.com 

All tstx users are in cen.example.com but their UPN is set to 
tstxx...@example.com 

I can run id and getent passwd commands without problem from both IPA servers: 

id tst99...@example.com 
uid=20018(tst99...@cen.example.com) gid=5001(csunix) 
groups=5001(csunix),93008(final_test_group) 

getent tst99...@example.com 
tst99...@cen.example.com:*:20018:5001:ipa_test:/home/cen.example.com/tst99655:/bin/bash
 

But from client: 

root@trh7clnt02:~# id tst99...@example.com 
id: tst99...@example.com: no such user 
root@trh7clnt02:~#getent passwd tst99...@example.com 
... no reply 


But when I run on client: 
getent group csu...@cen.example.com - it takes more then 30s 
csu...@cen.example.com:*:5001:  and really long list of users 

Then again from client: 

root@trh7clnt02:~# id tst99...@example.com 
uid=20018(tst99...@cen.example.com) gid=5001(csunix) groups=5001(csunix) 

root@trh7clnt02:~# getent passwd tst99...@example.com 
tst99...@cen.example.com:*:20018:5001:ipatest:/home/cen.example.com/tst99655:/bin/bash
 

This time it works and it keeps working until I clean the sssd cache on client. 
Then I have to run that getent group csunix command again. 

I would say it is some timeout issue with enumerating csunix group. I have 
tried to fix it by adding: 

ldap_search_timeout = 50 

into sssd.conf on both server and client(sssd restarted), but without effect. 
Here is my sssd.conf from client: 

[domain/vs.example.com] 
debug_level = 7 
cache_credentials = True 
krb5_store_password_if_offline = True 
ipa_domain = vs.example.com 
id_provider = ipa 
auth_provider = ipa 
access_provider = ipa 
ipa_hostname = trh7clnt02.vs.example.com 
chpass_provider = ipa 
ipa_server = tidmipa01.vs.example.com 
ldap_tls_cacert = /etc/ipa/ca.crt 
ldap_search_timeout = 50 

[sssd] 
services = nss, sudo, pam, ssh 
config_file_version = 2 
domains = vs.example.com 
[nss] 
homedir_substring = /home 
debug_level = 7 
[pam] 
debug_level = 7 
[sudo] 
[autofs] 
[ssh] 
[pac] 
debug_level = 7 
[ifp] 

IPA server sssd.conf: 

[domain/vs.example.com] 
debug_level = 7 
cache_credentials = True 
krb5_store_password_if_offline = True 
ipa_domain = vs.example.com 
id_provider = ipa 
auth_provider = ipa 
access_provider = ipa 
ipa_hostname = tidmipa01.vs.example.com 
chpass_provider = ipa 
ipa_server = tidmipa01.vs.example.com 
ipa_server_mode = True 
ldap_tls_cacert = /etc/ipa/ca.crt 
ldap_id_mapping = False 
ldap_search_timeout = 20 
[sssd] 
services = nss, sudo, pam, ssh 
config_file_version = 2 
domains = vs.example.com 
[nss] 
memcache_timeout = 600 
debug_level = 7 
homedir_substring = /home 
[pam] 
debug_level = 7 
[sudo] 
debug_level = 7 
[autofs] 
debug_level = 7 
[ssh] 
debug_level = 7 
[pac] 
debug_level = 7 
[ifp] 
debug_level = 7 

Any suggestion how to fix that ? I can add logs from both successful and 
unsuccessful try but they are quite long. 

Thank you. 
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] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

2017-01-03 Thread Martin Babinsky

On 01/02/2017 11:22 PM, Alan Latteri wrote:

I upgraded our FreeIPA server from Cent7.2 to 7.3 which also upgraded freeipa 
to 4.4.  On some clients they failed to re-authenticate post upgrade.  I then 
did an
ipa-client-install —uninstall , and then tried re-joining to IPA server with
ipa-client-install --mkhomedir --force-ntpd --force-join.

Now I am getting the below error, and I have no idea how to recover.  Firewall 
is disabled.

Thanks,
Alan

User authorized to enroll computers: admin
Password for admin@XXX.LOCAL:
Please make sure the following ports are opened in the firewall settings:
 TCP: 80, 88, 389
 UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly 
after enrollment:
 TCP: 464
 UDP: 464, 123 (if NTP enabled)
Kerberos authentication failed: kinit: Included profile directory could not be 
read while initializing Kerberos 5 library

Installation failed. Rolling back changes.
IPA client is not configured on this system.


[root@troll ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor 
preset: enabled)
   Active: inactive (dead)

Installed Packages
ipa-client.x86_64
4.4.0-14.el7.centos @updates
ipa-client-common.noarch 
4.4.0-14.el7.centos @updates
ipa-common.noarch
4.4.0-14.el7.centos @updates



Hi Alan,

it would be nice if you could post the client install log 
(/var/log/ipaclient-install.log). It is hard to tell what happens 
without seeing it.


--
Martin^3 Babinsky

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