Re: [Freeipa-users] FreeRadius and FreeIPA

2015-12-14 Thread Alexander Bokovoy 

On Wed, 09 Dec 2015, Randy Morgan wrote:

Hello,

We are setting up our wireless to authenticate against FreeRadius and 
FreeIPA.  I am looking for any instructions on how to integrate radius 
with IPA.  We can get them talking via kerberos, but when we have a 
wireless client attempt to authenticate against them, the password 
gets stripped out and only the username gets passed on, resulting in a 
failed logon attempt.


As we have studied the problem we have identified the communication 
protocols used by wireless to pass on the user credentials to radius.  
Wireless uses EAP as it's primary protocol.  We are running Xirrus 
wireless APs and from what we can learn, they act only as a pass 
through conduit for the client.  Ideally we would like them to speak 
PEAP TTLS, this would allow kerberos to process from the client to the 
IPA server, we are still researching this.


Are there any instructions on how to integrate FreeRadius 3.0.10 with 
FreeIPA 3.3.5?  Any help would be appreciated.

We see this question asked periodically. What we ask always prior to
answering it is what it would be used for? What authentication
mechanisms RADIUS is supposed to provide to its clients?

FreeRADIUS authenticating against IPA is easy. However, depending on
what authentication mechanisms are required it will be either not
possible to achieve or will definitely degrade security of the setup.

A general approach is to use following setup to use PAP authentication:
 1. Installing the 'freeradius-ldap' rpm from yum
 2. chmod 775 /etc/raddb/certs (so radiusd can write cert files)
 3. Change your 'authorize' and 'authenticate' sections of
 /etc/raddb/radiusd.conf to:
  authorize {
   ldap
 }
 authenticate {
   Auth-Type LDAP {
   ldap
   }
 }

During PAP a plaintext password is passed to the RADIUS server
(encrypted with a weak MD5 shared secret).

When the RADIUS server receives the users plaintext password in the
conventional configuration it simply compares the received password with
the stored password. The issue with IPA is there is no stored plaintext
password to compare to, therefore you cannot use conventional PAP with
IPA.

But FreeRADIUS permits you to do other things with PAP besides just
comparing the received password against the stored password for the
user. You can instruct FreeRADIUS to use what they call an
"authentication oracle", or at the risk of loose terminology to "proxy"
the authentication to another authentication server (not to be confused
with radius proxy where the radius transaction is proxied to another
radius server).

There are two authentication oracles FreeRADIUS can use

* LDAP
* Kerberos

In this scenario the plantext password received by the RADIUS server is
used to authenticate against the oracle. For LDAP it does a simple bind.
For Kerberos it does a kinit. If the authentication succeeds the RADIUS
server ACK's the PAP. The thing to note here is this is still occurring
with PAP but no password comparison is being performed.

There is a third "oracle" FreeRADIUS can utilize, namely Active
Directory, but in this case the protocol is not PAP, the ntlm_auth
helper from Samba is used instead with the RADIUS server communicating
with ntlm_auth which communicates with AD.

The suggestion of using strong passwords is always a good idea. The
password transmission between the client and the radius server only
enjoys weak protection so a strong password is especially important.
Communication between the RADIUS server and it's oracles can be quite
strong and is generally not a concern if things are configured properly.

Now, there is an issue if you would want to authenticate Windows clients
using MS CHAPv2 because that implies that FreeRADIUS would want to fetch
a weak NTLM hash to do negotiation on its own side.

To achieve that, one would need to give up the hashes to FreeRADIUS
instance. We consider them weak as they can be used to brute force
decryption of the passwords (trivially these days!) so a certain care
should be done to limit who can access them. We strongly not
recommending use of this but sometimes you are forced to provide
authentication for WiFi networks to Windows clients that only support

0. Run ipa-adtrust-install to configure IPA to generate NTLM hashes.
   Make sure you'll run the task to generate SIDs, ipa-adtrust-install
   will ask about it.

1. You need to create a system account for FreeRADIUS to acces the LDAP
   server. Let's say, it is
   uid=freeradius,cn=sysaccounts,cn=etc,dc=example,dc=com

2. Make the DN above a member of cn=adtrust 
agents,cn=sysaccounts,dc=example,dc=com
   Use the DN as in FreeRADIUS configuration.

3. For each user that needs to get NTLM hashes, a password change is
   required to regenerate all hashes. We currently have no means
   to generate them otherwise.

If you use ldap auth I'd suggest the connection either be SSL or on the
loopback to prevent snooping. Missing from instructions above is the

Re: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting

2015-12-14 Thread Jan Cholasta 

Hi,

On 14.12.2015 12:09, Martin Kosek wrote:

ipa-cacert-manage only renews CA certificate. It does not fix expired CA
subsystem certificates (#getcert list), IIRC.


Correct.



I think the process was:
- move system time to about 1-2 weeks before the oldest expired certificate
expiry time
- restart certmonnger
- now certmonger itself should start renewing the certificates. Other
alternative is to resubmit them with "getcert resubmit" command and see the 
results
- when done, time can be moved back

Honza (CCed), if I missed anything, please let me know.


This should work.



Martin

On 12/11/2015 08:54 PM, Jani West wrote:

Hello,

Seems like I indeed have expired certs. The problem is, how I can renew these.

I tried to do:
---
root@ipa1 ca]# systemctl restart dirsrv.target
[root@ipa1 ca]# ipa-cacert-manage renew
Renewing CA certificate, please wait
Error resubmitting certmonger request '20150814121620', please check the
request manually
---

I still have old certs:



Request ID '20150814121606':
 status: CA_WORKING
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='654666959930'
 certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
 CA: dogtag-ipa-ca-renew-agent
 issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
 subject: CN=CA Audit,O=PLANWEE.LOCAL
 expires: 2015-09-29 20:22:26 UTC
 key usage: digitalSignature,nonRepudiation
 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 '20150814121614':
 status: CA_WORKING
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='654666959930'
 certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
 CA: dogtag-ipa-ca-renew-agent
 issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
 subject: CN=OCSP Subsystem,O=PLANWEE.LOCAL
 expires: 2015-09-29 20:22:25 UTC
 key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
 eku: id-kp-OCSPSigning
 pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
 post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert
cert-pki-ca"
 track: yes
 auto-renew: yes
Request ID '20150814121618':
 status: CA_WORKING
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin='654666959930'
 certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB'
 CA: dogtag-ipa-ca-renew-agent
 issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
 subject: CN=CA Subsystem,O=PLANWEE.LOCAL
 expires: 2015-09-29 20:22:25 UTC
 key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
 eku: id-kp-serverAuth,id-kp-clientAuth
 pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
 post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert
cert-pki-ca"
 track: yes
 auto-renew: yes
Request ID '20150814121621':
 status: CA_WORKING
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
 certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
 CA: dogtag-ipa-ca-renew-agent
 issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
 subject: CN=IPA RA,O=PLANWEE.LOCAL
 expires: 2015-09-29 20:23:10 UTC
 key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
 eku: id-kp-serverAuth,id-kp-clientAuth
 pre-save command:
 post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
 track: yes
 auto-renew: yes

On 12/11/2015 10:23 AM, Martin Kosek wrote:

On 12/11/2015 08:31 AM, Jani West wrote:

Hello,

Pki-tomcatd seems to have difficulties when connecting to CA. LDAP
server is starting ok when starting it directly with "systemctl start
dirsrv.target".

When starting "systemctl start ipa" everything else will startup exept
the
pki-tomcatd.

Obviously same thing happens when starting with ipactl directly:
[root@ipa1 ca]# ipactl start
Existing service file detected!
Assuming stale, cleaning and proceeding
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl


/var/log/pki/pki-tomcat/localhost.2015-12-11.log
SEVERE:

Re: [Freeipa-users] Any recent guides for Postfix and IPA integration?

2015-12-14 Thread Martin Kosek 
On 12/12/2015 12:26 AM, Martin Štefany wrote:
> Hello Ranbir,
> 
> I'm working on this, even today I was putting more things together.
> (That DRAFT is really uncommented version of what I currently have). And
> I've opened also https://fedorahosted.org/freeipa/ticket/5521 to get a
> bit more out of it.
> 
> To sum it up what I've put together:
> - Postfix for SMTP MTA
> - Dovecot for IMAP (no POP3)
> - Amavisd-new with ClamAV and SpamAssassin for Antispam / Antivirus /
> additional header checks, etc.
> - SPF, DKIM, DMARC support for both sending and receiving mail
> - setup is HA thanks to DNS records, and 2 separate systems running
> almost identical configuration and Dovecot replicates mailboxes using
> dsync
> - PLAIN / LOGIN / GSSAPI authentication for SSO login thanks to FreeIPA
> (integration with Evolution on Fedora/RHEL/CentOS desktop joined to
> FreeIPA domain works also great)
> - users, of course, stored in FreeIPA, usage granted only to ones with
> correct e-mail field, group membership (and enablement of the ID)
> - but some pieces are still missing:
>   - I'm still reviewing e.g. correct postfix restrictions and
> documenting the full setup
>   - there's missing support for GUI configuration domain aliases, user
> aliases, sender/receiver Bcc support, quota setup, etc. even if
> something is managable via ipa-admintools and LDAP attributes
> 
> I would like to finish it asap, within a week or two, cause I run this
> e-mail system at home (as somebody already mentioned, why not?) and I
> don't like it unfinished. ;)
> 
> But to give you a good place to start: have a look to iRedMail project, 
> http://www.iredmail.org/, ZhangHuangbin's product is great and it helped
> me a lot to prepare what I described above. There's no support for 'old-
> style' HA, but you can still run it 'HA' on VM with all the benefits,
> and there's not direct support for FreeIPA integration, but guideline
> for ActiveDirectory integration exists, so you can start there: http://w
> ww.iredmail.org/docs/active.directory.html.
> 
> As Natxo mentioned, it all depends what kind of integration you want and
> what do you expect from mail setup. ;)
> 
> Martin

Looks as a decent amount of work included in this. BTW, if you have cycles to
contribute a How To to http://www.freeipa.org/page/HowTos or update/improve
existing guides there, I think other FreeIPA community members would be very
very grateful :-)

Thanks,
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] Yum update broke CA/CS - pki-tomcatd not starting

2015-12-14 Thread Martin Kosek 
ipa-cacert-manage only renews CA certificate. It does not fix expired CA
subsystem certificates (#getcert list), IIRC.

I think the process was:
- move system time to about 1-2 weeks before the oldest expired certificate
expiry time
- restart certmonnger
- now certmonger itself should start renewing the certificates. Other
alternative is to resubmit them with "getcert resubmit" command and see the 
results
- when done, time can be moved back

Honza (CCed), if I missed anything, please let me know.

Martin

On 12/11/2015 08:54 PM, Jani West wrote:
> Hello,
> 
> Seems like I indeed have expired certs. The problem is, how I can renew these.
> 
> I tried to do:
> ---
> root@ipa1 ca]# systemctl restart dirsrv.target
> [root@ipa1 ca]# ipa-cacert-manage renew
> Renewing CA certificate, please wait
> Error resubmitting certmonger request '20150814121620', please check the
> request manually
> ---
> 
> I still have old certs:
> 
> 
> 
> Request ID '20150814121606':
> status: CA_WORKING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='654666959930'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
> subject: CN=CA Audit,O=PLANWEE.LOCAL
> expires: 2015-09-29 20:22:26 UTC
> key usage: digitalSignature,nonRepudiation
> 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 '20150814121614':
> status: CA_WORKING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='654666959930'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
> subject: CN=OCSP Subsystem,O=PLANWEE.LOCAL
> expires: 2015-09-29 20:22:25 UTC
> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> eku: id-kp-OCSPSigning
> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
> "ocspSigningCert
> cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20150814121618':
> status: CA_WORKING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB',pin='654666959930'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
> subject: CN=CA Subsystem,O=PLANWEE.LOCAL
> expires: 2015-09-29 20:22:25 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert
> cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20150814121621':
> status: CA_WORKING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL
> subject: CN=IPA RA,O=PLANWEE.LOCAL
> expires: 2015-09-29 20:23:10 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
> track: yes
> auto-renew: yes
> 
> On 12/11/2015 10:23 AM, Martin Kosek wrote:
>> On 12/11/2015 08:31 AM, Jani West wrote:
>>> Hello,
>>>
>>> Pki-tomcatd seems to have difficulties when connecting to CA. LDAP
>>> server is starting ok when starting it directly with "systemctl start
>>> dirsrv.target".
>>>
>>> When starting "systemctl start ipa" everything else will startup exept
>>> the
>>> pki-tomcatd.
>>>
>>> Obviously same thing happens when starting with ipactl directly:
>>> [root@ipa1 ca]# ipactl start
>>> Existing service file detected!
>>> Assuming stale, cleaning and proceeding
>>> Starting Directory Service
>>> Starting krb5kdc Service
>>> Starting kadmin Service
>>> Starting named Service
>>> Starting ipa_memcached Service
>>> Starting httpd Service
>>> Starting

Re: [Freeipa-users] Clean up DNS Host Cert and other records from IPA

2015-12-14 Thread Martin Kosek 
On 12/11/2015 11:55 PM, Andrey Ptashnik wrote:
> Hello Team,
> 
> We have many servers in our environment that are on a different stage of 
> their lifecycle. All of them are added to IPA domain. There are cases when 
> servers gets moved, sometimes crash, sometimes are being rebuild or 
> decommissioned. In those cases we need to completely remove server identity 
> from IPA including DNS, Host, Certificate and other associated records.
> What is the most proper way to completely remove client records in case if 
> server needs to be rebuilt with the same host name down the road? (hardware 
> failure happened, server crashed and needs to be rebuild – is a perfect 
> example).

ipa host-del command (can be also with --updatedns flag) should remove all
services and revoke certificates active for the host or service records. Is
that insufficient or maybe not working for you?

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] Clean up DNS, Host, Cert and other records from IPA / IDM

2015-12-14 Thread Alexander Bokovoy 

On Fri, 11 Dec 2015, Andrey Ptashnik wrote:

Hello Team,

We have many servers in our environment that are on a different stage
of their lifecycle. All of them are added to IPA domain. There are
cases when servers gets moved, sometimes crash, sometimes are being
rebuild or decommissioned. In those cases we need to completely remove
server identity from IPA including DNS, Host, Certificate and other
associated records.
What is the most proper way to completely remove client records in case
if server needs to be rebuilt with the same host name down the road?
(hardware failure happened, server crashed and needs to be rebuild – is
a perfect example).

'ipa-client-install --uninstall' results in calling 'ipa-join --unenroll -h 
hostname'
which in turn calls 'ipa host-disable hostname'. The latter on the
IPA server side does following:
- disables the host entry
- disables any service associated with the host
- revokes certificates associated with the host
- removes keytab associated with the host

Disabling services involves revoking of certificates and removal of
keytabs associated with these services.

Of course, 'keytab removal' means only that the keys are removed from
LDAP entries, not that keytab files are removed.

Note that none of DNS entries are removed.

If you don't have hosts anymore, you can issue 'ipa host-disable hostname'
from any other host under credentials of a user that has enough
privileges to remove the host and associated services. 'admins' group
membership should be strong enough to achieve this goal.

--
/ 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] FreeRadius and FreeIPA

2015-12-14 Thread Randy Morgan 
Thanks Alexander, that was an excellent explanation with some very 
helpful information.  We will look over our configs and see if we can 
work this out.


Randy

Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100

On 12/14/2015 3:12 AM, Alexander Bokovoy wrote:

On Wed, 09 Dec 2015, Randy Morgan wrote:

Hello,

We are setting up our wireless to authenticate against FreeRadius and 
FreeIPA.  I am looking for any instructions on how to integrate 
radius with IPA.  We can get them talking via kerberos, but when we 
have a wireless client attempt to authenticate against them, the 
password gets stripped out and only the username gets passed on, 
resulting in a failed logon attempt.


As we have studied the problem we have identified the communication 
protocols used by wireless to pass on the user credentials to 
radius.  Wireless uses EAP as it's primary protocol.  We are running 
Xirrus wireless APs and from what we can learn, they act only as a 
pass through conduit for the client.  Ideally we would like them to 
speak PEAP TTLS, this would allow kerberos to process from the client 
to the IPA server, we are still researching this.


Are there any instructions on how to integrate FreeRadius 3.0.10 with 
FreeIPA 3.3.5?  Any help would be appreciated.

We see this question asked periodically. What we ask always prior to
answering it is what it would be used for? What authentication
mechanisms RADIUS is supposed to provide to its clients?

FreeRADIUS authenticating against IPA is easy. However, depending on
what authentication mechanisms are required it will be either not
possible to achieve or will definitely degrade security of the setup.

A general approach is to use following setup to use PAP authentication:
 1. Installing the 'freeradius-ldap' rpm from yum
 2. chmod 775 /etc/raddb/certs (so radiusd can write cert files)
 3. Change your 'authorize' and 'authenticate' sections of
 /etc/raddb/radiusd.conf to:
  authorize {
   ldap
 }
 authenticate {
   Auth-Type LDAP {
   ldap
   }
 }

During PAP a plaintext password is passed to the RADIUS server
(encrypted with a weak MD5 shared secret).

When the RADIUS server receives the users plaintext password in the
conventional configuration it simply compares the received password with
the stored password. The issue with IPA is there is no stored plaintext
password to compare to, therefore you cannot use conventional PAP with
IPA.

But FreeRADIUS permits you to do other things with PAP besides just
comparing the received password against the stored password for the
user. You can instruct FreeRADIUS to use what they call an
"authentication oracle", or at the risk of loose terminology to "proxy"
the authentication to another authentication server (not to be confused
with radius proxy where the radius transaction is proxied to another
radius server).

There are two authentication oracles FreeRADIUS can use

* LDAP
* Kerberos

In this scenario the plantext password received by the RADIUS server is
used to authenticate against the oracle. For LDAP it does a simple bind.
For Kerberos it does a kinit. If the authentication succeeds the RADIUS
server ACK's the PAP. The thing to note here is this is still occurring
with PAP but no password comparison is being performed.

There is a third "oracle" FreeRADIUS can utilize, namely Active
Directory, but in this case the protocol is not PAP, the ntlm_auth
helper from Samba is used instead with the RADIUS server communicating
with ntlm_auth which communicates with AD.

The suggestion of using strong passwords is always a good idea. The
password transmission between the client and the radius server only
enjoys weak protection so a strong password is especially important.
Communication between the RADIUS server and it's oracles can be quite
strong and is generally not a concern if things are configured properly.

Now, there is an issue if you would want to authenticate Windows clients
using MS CHAPv2 because that implies that FreeRADIUS would want to fetch
a weak NTLM hash to do negotiation on its own side.

To achieve that, one would need to give up the hashes to FreeRADIUS
instance. We consider them weak as they can be used to brute force
decryption of the passwords (trivially these days!) so a certain care
should be done to limit who can access them. We strongly not
recommending use of this but sometimes you are forced to provide
authentication for WiFi networks to Windows clients that only support

0. Run ipa-adtrust-install to configure IPA to generate NTLM hashes.
   Make sure you'll run the task to generate SIDs, ipa-adtrust-install
   will ask about it.

1. You need to create a system account for FreeRADIUS to acces the LDAP
   server. Let's say, it is
   uid=freeradius,cn=sysaccounts,cn=etc,dc=example,dc=com

2. Make the DN above a member of cn=adtrust 
agents,cn=sysaccounts,dc=example,dc=com

   Use the DN as in FreeRADIUS configuration.

3. For

Re: [Freeipa-users] otpd heavy load?

2015-12-14 Thread Alexander Bokovoy 

On Thu, 10 Dec 2015, Janelle wrote:

libverto-tevent-0.2.5-4.el7.x86_64
libverto-0.2.5-4.el7.x86_64

Patching problem perhaps?

Can you install debuginfo for krb5 and ipa? And then install  ltrace?

I would go with these tools:
- once ipa-otpd recreates its high resource usage, run 'pstack '
  periodically to take few snapshots of its stacktraces
- do 'ltrace -s 256 -S -ttt -T -r -p '

Save the reports you'd get, and make them available to us. They will be
big enough, so avoid sending it to the list, send privately.



On 12/10/15 10:49 AM, Nathaniel McCallum wrote:

Please provide the output of the 'rpm -qa libverto*' command.

On Thu, 2015-12-10 at 10:13 -0800, Janelle wrote:

RHEL 7.1

On 12/10/15 9:55 AM, Nathaniel McCallum wrote:

On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote:

Hi,

Hope everyone is enjoying the holiday season. Been away for
sometime,
and wanted to jump in with a new question.  I am seeing otpd have
high
resource usage (from just monitoring via top, sar and uptime)
however, I
can not seem to find any logging from it, nor how I might be able
to
enable some in order to find out why it is using so much CPU? Any
thoughts/suggestions?

Log messages should be available through journalctl.

Which libverto backend are you running? If you are on Fedora,
please
provide the output of the 'rpm -qa libverto*' command.


--
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] Any recent guides for Postfix and IPA integration?

2015-12-14 Thread Ranbir 
On Sun, 2015-12-13 at 21:56 +0100, Natxo Asenjo wrote:
> so what have you tried?

A number of things. However, I've been able to get past the SASL GSSAPI
error I was seeing in Postfix. Now I've run into another issue though I
don't think it's related to freeipa.

I'm going to post what I did once I have a working setup. In the
meantime, I have other questions.

How would one handle an email only user in freeipa? I have mail
accounts that aren't attached to a real person and yet I need the
"user" to exist in freeipa.

-- 
Ranbir


signature.asc
Description: This is a digitally signed message part
-- 
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] otpd heavy load?

2015-12-14 Thread Janelle 

I'll gather up the info first chance I get.

Thank you
~J

On 12/14/15 7:35 AM, Alexander Bokovoy wrote:

On Thu, 10 Dec 2015, Janelle wrote:

libverto-tevent-0.2.5-4.el7.x86_64
libverto-0.2.5-4.el7.x86_64

Patching problem perhaps?

Can you install debuginfo for krb5 and ipa? And then install ltrace?

I would go with these tools:
- once ipa-otpd recreates its high resource usage, run 'pstack '
  periodically to take few snapshots of its stacktraces
- do 'ltrace -s 256 -S -ttt -T -r -p '

Save the reports you'd get, and make them available to us. They will be
big enough, so avoid sending it to the list, send privately.



On 12/10/15 10:49 AM, Nathaniel McCallum wrote:

Please provide the output of the 'rpm -qa libverto*' command.

On Thu, 2015-12-10 at 10:13 -0800, Janelle wrote:

RHEL 7.1

On 12/10/15 9:55 AM, Nathaniel McCallum wrote:

On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote:

Hi,

Hope everyone is enjoying the holiday season. Been away for
sometime,
and wanted to jump in with a new question.  I am seeing otpd have
high
resource usage (from just monitoring via top, sar and uptime)
however, I
can not seem to find any logging from it, nor how I might be able
to
enable some in order to find out why it is using so much CPU? Any
thoughts/suggestions?

Log messages should be available through journalctl.

Which libverto backend are you running? If you are on Fedora,
please
provide the output of the 'rpm -qa libverto*' command.


--
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] AD group members

2015-12-14 Thread Winfried de Heiden 

  
  
Using an EL7 client, lot's of times the IPA
  (posix) groups are missing, or partly missing. Doing some
  debugging, sssd_pac.log shows:

(Mon Dec 14 17:19:08 2015)
[sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID
[S-1-5-21-1802245919-2979536009-1783284443-51509] is not in the
PAC anymore, membership must be removed.
(Mon Dec 14 17:19:08 2015) [sssd[pac]]
  [pac_user_get_grp_info] (0x2000): Group with SID
  [S-1-5-21-1802245919-2979536009-1783284443-51508] is not in the
  PAC anymore, membership must be removed.
  
  These sids are the groups I am missing. What is happening here???
  
  Kind regards,
  
  Winny

  


-- 
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] Any recent guides for Postfix and IPA integration?

2015-12-14 Thread Ranbir 
On Mon, 2015-12-14 at 11:30 -0500, Ranbir wrote:
> How would one handle an email only user in freeipa? I have mail
> accounts that aren't attached to a real person and yet I need the
> "user" to exist in freeipa.

Should I just create a normal user account, set the password and mail
and disable logins?

-- 
Ranbir


signature.asc
Description: This is a digitally signed message part
-- 
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] Any recent guides for Postfix and IPA integration?

2015-12-14 Thread Simo Sorce 
On Mon, 2015-12-14 at 13:38 -0500, Ranbir wrote:
> On Mon, 2015-12-14 at 11:30 -0500, Ranbir wrote:
> > How would one handle an email only user in freeipa? I have mail
> > accounts that aren't attached to a real person and yet I need the
> > "user" to exist in freeipa.
> 
> Should I just create a normal user account, set the password and mail
> and disable logins?

There are a few ways to go about it.

another way is to use a custom subtree + schema to store these emails
only.

It really depends on what kind of tools you want to use to manage the
information too.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] Clean up DNS, Host, Cert and other records from IPA / IDM

2015-12-14 Thread Andrey Ptashnik 
Alexander,

Thank you for your feedback, this is what I expected to do - 
'ipa-client-install —uninstall' and expected and easy quick fix for my request. 
It seem to work in environment where server portion is on CentOS/RHEL 7.1 and 
clients as well on 7.1 with IPA 4.1

However when clients are little older like CentOS/RHEL 6.5-6.6 behavior in our 
case was different, we had to manually delete records with "ipa host-del” 
command like Martin Kosek mentioned.

So I wanted to reiterate with Red Hat team if 'ipa-client-install —uninstall' 
is still the proper way to clean up records completely. Additionally if I can 
expect the same behavior on client versions lower than CentOS/RHEL 7.1 + IPA 4.1

Regards,

Andrey Ptashnik 







On 12/14/15, 4:21 AM, "Alexander Bokovoy"  wrote:

>On Fri, 11 Dec 2015, Andrey Ptashnik wrote:
>>Hello Team,
>>
>>We have many servers in our environment that are on a different stage
>>of their lifecycle. All of them are added to IPA domain. There are
>>cases when servers gets moved, sometimes crash, sometimes are being
>>rebuild or decommissioned. In those cases we need to completely remove
>>server identity from IPA including DNS, Host, Certificate and other
>>associated records.
>>What is the most proper way to completely remove client records in case
>>if server needs to be rebuilt with the same host name down the road?
>>(hardware failure happened, server crashed and needs to be rebuild – is
>>a perfect example).
>'ipa-client-install --uninstall' results in calling 'ipa-join --unenroll -h 
>hostname'
>which in turn calls 'ipa host-disable hostname'. The latter on the
>IPA server side does following:
> - disables the host entry
> - disables any service associated with the host
> - revokes certificates associated with the host
> - removes keytab associated with the host
>
>Disabling services involves revoking of certificates and removal of
>keytabs associated with these services.
>
>Of course, 'keytab removal' means only that the keys are removed from
>LDAP entries, not that keytab files are removed.
>
>Note that none of DNS entries are removed.
>
>If you don't have hosts anymore, you can issue 'ipa host-disable hostname'
>from any other host under credentials of a user that has enough
>privileges to remove the host and associated services. 'admins' group
>membership should be strong enough to achieve this goal.
>
>-- 
>/ 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

[Freeipa-users] confused about replica role and use

2015-12-14 Thread Karl Forner 
Hello,

>From what I understood, a freeipa replica server is a kind of backup of
another freeipa server.
Both are usable by clients, and they will dynamically update their
information.

But I do not understand how a client will make use of the replica if the
master server is down.
Naively I would imagine, that like for DNS servers, that you configure a
main freeipa server, and a secondary one in case the main one does not
respond, but I can not find how to do it.
Is this happening automagically ? Or this is not the way it is supposed to
be used ?

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