Re: [Freeipa-users] change CA subject or "friendly name"?

[Jan Cholasta]

Hi,

On 12.4.2016 01:08, Fraser Tweedale wrote:

On Mon, Apr 11, 2016 at 11:43:17AM -0400, Anthony Clark wrote:

Hello All,

I'm in the process of deploying FreeIPA 4 in a development environment.
One of my testers has imported the ca.pem file into Windows, and indicates
that it displays as:

Issued to: Certificate Authority
Issued by: Certificate Authority
Friendly Name: 

This will unfortunately cause confusion among certain end users, so I was
wondering if there's a way to change those attributes?

Ideally without reinstalling everything, but thankfully we're still early
in the process so it's OK if do blow everything away.

Do I need to generate a new CA outside of FreeIPA and then use
ipa-cacert-manage to "renew" the base CA?

Thanks,

Anthony Clark


Hi Anthony,

After a brief investigation it appears that ``Friendly Name'' is a
property that can be set in a Windows certificate store, and is not
part of, or derived from, the certificate itself.

Here are a couple of TechNet articles that might help:

- https://technet.microsoft.com/en-us/library/cc740218%28v=ws.10%29.aspx
- 
https://blogs.technet.microsoft.com/pki/2008/12/12/defining-the-friendly-name-certificate-property/


As for "Issued to" and "Issued by", I guess these are derived from the 
subject and issuer name fields of the certificate, which currently can't 
be changed for our CA certificate.


We have a ticket to fix this for quite some time: 
.


--
Jan Cholasta

--
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] Adding FreeIPA to an existing infrastructure

[Jan Cholasta]

On 18.4.2016 12:20, Martin Kosek wrote:

On 04/12/2016 12:14 PM, Remco Kranenburg wrote:

Thanks for all the pointers. I'm tentatively moving forward with a CA-less and
DNS-less IPA server, with Letsencrypt certificates. I think this is also the
setup that is used by the demo at . Is
there some documentation about this setup?


I installed this FreeIPA Demo server with Dogtag CA and then used something
like this to setup the root cert:


# do this once before taking snapshot of the VM
dnf install letsencrypt -y

ipa-cacert-manage install le-root-ca.pem -n le-root-ca -t ,,
ipa-certupdate -v

ipa-cacert-manage install le-authority-x1.pem -n le-authority-x1 -t C,,
ipa-certupdate -v


and then generated LE certificate:


# generate CSR
certutil -R -d /etc/httpd/alias/ -k Server-Cert -f /etc/httpd/alias/pwdfile.txt
-s "CN=$(hostname)" --extSAN "dns:$(hostname)" -a -o /root/httpd-csr.pem
openssl req -in /root/httpd-csr.pem -outform der -out /root/httpd-csr.der

# httpd process prevents letsencrypt from working, stop it
service httpd stop

# get a new cert
letsencrypt certonly --csr /root/httpd-csr.der --email ...@redhat.com 
--agree-tos

# remove old cert
certutil -D -d /etc/httpd/alias/ -n Server-Cert
# add the new cert
certutil -A -d /etc/httpd/alias/ -n Server-Cert -t ,, -a -i /root/_cert.pem

# start httpd with the new cert
service httpd start


but you probably do not want this as you are not installing CA piece.


I'm trying to install a Letsencrypt
certificate into FreeIPA, but when I run the installation:

ipa-server-install --http-cert-file cert.pem --http-cert-file privkey.pem
--dirsrv-cert-file cert.pem --dirsrv-cert-file privkey.pem

It asks for my "Apache Server private key unlock password", even though the key
from Letsencrypt is not encrypted with a passphrase.


Try using empty passphrase: --http-pin= --dirsrv-pin=


When I give a bogus

password, it gives me another error:

ipa.ipapython.install.cli.install_tool(Server): ERRORThe full certificate
chain is not present in cert.pem, privkey.pem

Letsencrypt provides me with a few files: cert.pem, chain.pem, fullchain.pem,
privkey.pem. Even when I also add chain.pem and fullchain.pem, it gives me the
same error.


The error is legit, you have to specify the full CA certificate chain 
using --ca-cert-file.




CCing JanC, he is the man to help with this one.

Martin




--
Jan Cholasta

--
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] NEEDED_PREAUTH: Additional pre-authentication required - User can't access any centos server

[Sumit Bose]

On Mon, Apr 18, 2016 at 03:08:28PM +, Gady Notrica wrote:
> Hi guys,
> 
> >From the ipa server, I am having issue with the single user. Everyone else 
> >is fine, just this one single user and no help anywhere online.
> 
> Please help!
> 
> Thank you
> 
> Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes {18 17 
> 16 23 25 26}) 172.20.10.40: NEEDED_PREAUTH: bcos...@ipa.domain.com for 
> krbtgt/ipa.domain@ipa.domain.com, Additional pre-authentication required

NEEDED_PREAUTH is expected

> Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): closing down fd 12
> Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): preauth 
> (encrypted_timestamp) verify failure: Decrypt integrity check failed

This indicates a wrong password.

HTH

bye,
Sumit

> Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes {18 17 
> 16 23 25 26}) 172.20.10.40: PREAUTH_FAILED: bcos...@ipa.domain.com for 
> krbtgt/ipa.domain@ipa.domain.com, Decrypt integrity check failed
> Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): closing down fd 12
> Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes {18 17 
> 16 23 25 26}) 172.20.10.40: NEEDED_PREAUTH: bcos...@ipa.domain.com for 
> krbtgt/ipa.domain@ipa.domain.com, Additional pre-authentication required
> Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): closing down fd 12
> Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): preauth 
> (encrypted_timestamp) verify failure: Decrypt integrity check failed
> Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes {18 17 
> 16 23 25 26}) 172.20.10.40: PREAUTH_FAILED: bcos...@ipa.domain.com for 
> krbtgt/ipa.domain@ipa.domain.com, Decrypt integrity check failed
> 
> Gady Notrica | IT Systems Analyst | 416.814.7800 Ext. 7921 | Cell. 
> 416.818.4797 | gnotr...@candeal.com
> CanDeal | 152 King St. E, 4th Floor, Toronto ON M5A 1J4 | 
> www.candeal.com | Follow us: [Description: 
> Description: cid:image003.jpg@01CBD419.622CDF90] 
>    [Description: Description: Description: 
> cid:image002.jpg@01CBD419.622CDF90] 
> 
> 




> -- 
> 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] NEEDED_PREAUTH: Additional pre-authentication required - User can't access any centos server

[Gady Notrica]

Hi Rob,

Thanks for the reply. I did reset the user password multiple times to a simple 
password, still having same issue.

Gady

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: April 18, 2016 2:25 PM
To: Gady Notrica; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] NEEDED_PREAUTH: Additional pre-authentication 
required - User can't access any centos server

Gady Notrica wrote:
> Hi guys,
>
>  From the ipa server, I am having issue with the single user. Everyone 
> else is fine, just this one single user and no help anywhere online.
>
> Please help!

Decrypt integrity check failed almost always means bad password.

rob

>
> Thank you
>
> Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes 
> {18
> 17 16 23 25 26}) 172.20.10.40: *NEEDED_PREAUTH*: 
> bcos...@ipa.domain.com for krbtgt/ipa.domain@ipa.domain.com, 
> *Additional pre-authentication
> required*
>
> Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): closing down fd 12
>
> Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): preauth
> (encrypted_timestamp) verify failure: *Decrypt integrity check failed*
>
> Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes 
> {18
> 17 16 23 25 26}) 172.20.10.40: *PREAUTH_FAILED*: 
> bcos...@ipa.domain.com for krbtgt/ipa.domain@ipa.domain.com, 
> Decrypt integrity check failed
>
> Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): closing down fd 12
>
> Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes 
> {18
> 17 16 23 25 26}) 172.20.10.40: *NEEDED_PREAUTH*: 
> bcos...@ipa.domain.com for krbtgt/ipa.domain@ipa.domain.com, 
> *Additional pre-authentication
> required*
>
> Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): closing down fd 12
>
> Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): preauth
> (encrypted_timestamp) verify failure: *Decrypt integrity check failed*
>
> Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes 
> {18
> 17 16 23 25 26}) 172.20.10.40: *PREAUTH_FAILED*: 
> bcos...@ipa.domain.com for krbtgt/ipa.domain@ipa.domain.com, 
> Decrypt integrity check failed
>
>
>
>


-- 
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] NEEDED_PREAUTH: Additional pre-authentication required - User can't access any centos server

[Rob Crittenden]

Gady Notrica wrote:

Hi guys,

 From the ipa server, I am having issue with the single user. Everyone
else is fine, just this one single user and no help anywhere online.

Please help!


Decrypt integrity check failed almost always means bad password.

rob



Thank you

Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes {18
17 16 23 25 26}) 172.20.10.40: *NEEDED_PREAUTH*: bcos...@ipa.domain.com
for krbtgt/ipa.domain@ipa.domain.com, *Additional pre-authentication
required*

Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): closing down fd 12

Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): preauth
(encrypted_timestamp) verify failure: *Decrypt integrity check failed*

Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes {18
17 16 23 25 26}) 172.20.10.40: *PREAUTH_FAILED*: bcos...@ipa.domain.com
for krbtgt/ipa.domain@ipa.domain.com, Decrypt integrity check failed

Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): closing down fd 12

Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes {18
17 16 23 25 26}) 172.20.10.40: *NEEDED_PREAUTH*: bcos...@ipa.domain.com
for krbtgt/ipa.domain@ipa.domain.com, *Additional pre-authentication
required*

Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): closing down fd 12

Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): preauth
(encrypted_timestamp) verify failure: *Decrypt integrity check failed*

Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes {18
17 16 23 25 26}) 172.20.10.40: *PREAUTH_FAILED*: bcos...@ipa.domain.com
for krbtgt/ipa.domain@ipa.domain.com, Decrypt integrity check failed

Gady Notrica| IT Systems Analyst | 416.814.7800 Ext. 7921 | Cell.
416.818.4797 | gnotr...@candeal.com 

CanDeal | 152 King St. E, 4th Floor, Toronto ON M5A 1J4 |
www.candeal.com | Follow us:Description:
Description: cid:image003.jpg@01CBD419.622CDF90
*Description: Description: Description:
cid:image002.jpg@01CBD419.622CDF90*






--
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] Account/password expirations

[Steve Huston]

Following instructions in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-pwd-expiry.html
sort-of works to get this done, but I wonder if there's a better way
to do it.  My goal is twofold: when users are created, they will be
required to have a krbPrincipalExpiration, and they should be denied
login if that date has passed; and users should be prompted to change
their password if krbPasswordExpiration has passed.  It would be
beneficial to have warnings printed for at least password expiration,
but ideally account expiration, as well.  These should be checked and
output if the user is using public key authentication as well as
passwords and GSSAPI.

If I set 'access_provider = ldap' in sssd.conf, it seems to work (also
setting ldap_access_order to pwd_expire_policy_renew, and a filter
which I've yet to determine, otherwise all logins are rejected
anyway).  My understanding from
https://fedorahosted.org/sssd/ticket/1227 is that HBAC will then fail
to work.  Will other things, such as disabling the account, also fail?
 What about password lockouts?

Is there a better way to do this, for example one that keeps
access_provider set to ipa and consults IPA directly?  Of course
doesn't help that I need to deal with this across multiple OSs (CentOS
5 using LDAP explicitly, 6 and 7 using sssd)

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
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] NEEDED_PREAUTH: Additional pre-authentication required - User can't access any centos server

[Gady Notrica]

Hi guys,

>From the ipa server, I am having issue with the single user. Everyone else is 
>fine, just this one single user and no help anywhere online.

Please help!

Thank you

Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes {18 17 16 
23 25 26}) 172.20.10.40: NEEDED_PREAUTH: bcos...@ipa.domain.com for 
krbtgt/ipa.domain@ipa.domain.com, Additional pre-authentication required
Apr 15 15:43:36 ipa.domain.com krb5kdc[2568](info): closing down fd 12
Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): preauth 
(encrypted_timestamp) verify failure: Decrypt integrity check failed
Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes {18 17 16 
23 25 26}) 172.20.10.40: PREAUTH_FAILED: bcos...@ipa.domain.com for 
krbtgt/ipa.domain@ipa.domain.com, Decrypt integrity check failed
Apr 15 15:43:41 ipa.domain.com krb5kdc[2565](info): closing down fd 12
Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): AS_REQ (6 etypes {18 17 16 
23 25 26}) 172.20.10.40: NEEDED_PREAUTH: bcos...@ipa.domain.com for 
krbtgt/ipa.domain@ipa.domain.com, Additional pre-authentication required
Apr 15 15:43:49 ipa.domain.com krb5kdc[2568](info): closing down fd 12
Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): preauth 
(encrypted_timestamp) verify failure: Decrypt integrity check failed
Apr 15 15:43:55 ipa.domain.com krb5kdc[2565](info): AS_REQ (6 etypes {18 17 16 
23 25 26}) 172.20.10.40: PREAUTH_FAILED: bcos...@ipa.domain.com for 
krbtgt/ipa.domain@ipa.domain.com, Decrypt integrity check failed

Gady Notrica | IT Systems Analyst | 416.814.7800 Ext. 7921 | Cell. 416.818.4797 
| gnotr...@candeal.com
CanDeal | 152 King St. E, 4th Floor, Toronto ON M5A 1J4 | 
www.candeal.com | Follow us: [Description: Description: 
cid:image003.jpg@01CBD419.622CDF90]    
[Description: Description: Description: cid:image002.jpg@01CBD419.622CDF90] 


-- 
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] Username attribute in trusted domain

[Jakub Hrozek]

On Mon, Apr 18, 2016 at 01:47:04PM +, Brook, Andy [CRI] wrote:
> 
> On 4/18/16, 5:03 AM, "freeipa-users-boun...@redhat.com on behalf of Jakub 
> Hrozek"  
> wrote:
> 
> >On Fri, Apr 15, 2016 at 08:01:06PM +, Brook, Andy [CRI] wrote:
> >> We’re trying to setup FreeIPA to be a good provider of UIDs and GIDs for 
> >> our mostly RHEL systems. Overall, that works great. The issue I’m running 
> >> into is that we need to have the same consistent UIDs and GIDs for our 
> >> Isilon system which serves up both CIFS and NFS. Each user of the Isilon 
> >> needs to have a UID so that the files are owned properly. The Isilon has a 
> >> way of getting information from both Active Directory and an associated 
> >> LDAP server. It gets its list of users and groups from AD, a list of 
> >> users, UIDs, groups and GIDs from LDAP, and combine accounts that are the 
> >> same. i.e. ADTEST.LOCAL\abrook and abrook from LDAP will the same user. 
> >> However, FreeIPA will show abrook(as it sees through the Trust 
> >> relationship with ADTEST.LOCAL) as 
> >> abrook@adtest.local instead of abrook, so the 
> >> Isilon will see them as distinct accounts and won’t merge the information 
> >> in them. I can’t, as far as I can tell right now, tell the Isilon to see 
> >> users with @adtest.local as the same user without the domain. I can tell 
> >> the Isilon to look at a different LDAP attribute as its username, but 
> >> there is no attribute that has only the username.
> >> 
> >> I noticed in the documentation that if I were to do a sync with Active 
> >> Directory (which isn’t something I want to do), I would get the 
> >> ntDomainUserID attribute that is the same as the samAccountName. This 
> >> doesn’t happen with a trust. Is there a way to get that in place with a 
> >> custom attribute or pull more LDAP attributes from AD?
> >> 
> >> Has anyone else run into a situation like this? If so, were you able to 
> >> rectify that? If so, how?
> >> 
> >> We have a ticket open with EMC for the Isilon as well, but want to make 
> >> sure we’re coming at this from all the angles we can.
> >
> >I'm sorry, but currently overriding the attribute names for AD trusted
> >domains is not possible. We are working to make it possible for the next
> >version, but it's a bit of a stretch goal already, so chances it won't
> >be ready only for the version after the next one.
> >
> >What might perhaps help you is that starting with upstream SSSD 1.14
> >(upstream 7.3), it should be possible to configure SSSD to only print
> >the shortname and not qualify the users in trusted domains.
> >
> 
> Thank you. In your suggestion, are you talking about SSSD on the IPA
> Servers? My understanding of how SSSD on the IPA servers interacts with
> the servers that talk to them is pretty limited. If I upgrade SSSD on
> these servers, I might be able to get LDAP to not print the qualifying
> domain during ldapsearch?

Depends on how you want to query the information, whether with "getent
passwd $user" or ldapsearch. SSSD itself doesn't provide any data to
ldapsearch, but provides NSS, PAM and D-Bus interfaces.

And you'd have to upgrade SSSD on both clients and servers.

> 
> I’m not really asking about overriding attribute names, but rather
> adding a new attribute that only has the shortname. Is there a way to
> do that may through a custom NIS mapping or something like that? Maybe
> a dynamic schema extension? I’ve tried reading through extending the
> schema, but am currently confused as to how to go about it.

It sounds like the new attribute would be added on the AD side, but at
the moment, SSSD's attribute map for the trusted domains is hardcoded.

The only way would be to query the attribute through our d-bus API.

-- 
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] Username attribute in trusted domain

[Brook, Andy [CRI]]

On 4/18/16, 5:03 AM, "freeipa-users-boun...@redhat.com on behalf of Jakub 
Hrozek"  
wrote:

>On Fri, Apr 15, 2016 at 08:01:06PM +, Brook, Andy [CRI] wrote:
>> We’re trying to setup FreeIPA to be a good provider of UIDs and GIDs for our 
>> mostly RHEL systems. Overall, that works great. The issue I’m running into 
>> is that we need to have the same consistent UIDs and GIDs for our Isilon 
>> system which serves up both CIFS and NFS. Each user of the Isilon needs to 
>> have a UID so that the files are owned properly. The Isilon has a way of 
>> getting information from both Active Directory and an associated LDAP 
>> server. It gets its list of users and groups from AD, a list of users, UIDs, 
>> groups and GIDs from LDAP, and combine accounts that are the same. i.e. 
>> ADTEST.LOCAL\abrook and abrook from LDAP will the same user. However, 
>> FreeIPA will show abrook(as it sees through the Trust relationship with 
>> ADTEST.LOCAL) as abrook@adtest.local instead of 
>> abrook, so the Isilon will see them as distinct accounts and won’t merge the 
>> information in them. I can’t, as far as I can tell right now, tell the 
>> Isilon to see users with @adtest.local as the same user without the domain. 
>> I can tell the Isilon to look at a different LDAP attribute as its username, 
>> but there is no attribute that has only the username.
>> 
>> I noticed in the documentation that if I were to do a sync with Active 
>> Directory (which isn’t something I want to do), I would get the 
>> ntDomainUserID attribute that is the same as the samAccountName. This 
>> doesn’t happen with a trust. Is there a way to get that in place with a 
>> custom attribute or pull more LDAP attributes from AD?
>> 
>> Has anyone else run into a situation like this? If so, were you able to 
>> rectify that? If so, how?
>> 
>> We have a ticket open with EMC for the Isilon as well, but want to make sure 
>> we’re coming at this from all the angles we can.
>
>I'm sorry, but currently overriding the attribute names for AD trusted
>domains is not possible. We are working to make it possible for the next
>version, but it's a bit of a stretch goal already, so chances it won't
>be ready only for the version after the next one.
>
>What might perhaps help you is that starting with upstream SSSD 1.14
>(upstream 7.3), it should be possible to configure SSSD to only print
>the shortname and not qualify the users in trusted domains.
>

Thank you. In your suggestion, are you talking about SSSD on the IPA Servers? 
My understanding of how SSSD on the IPA servers interacts with the servers that 
talk to them is pretty limited. If I upgrade SSSD on these servers, I might be 
able to get LDAP to not print the qualifying domain during ldapsearch? 

I’m not really asking about overriding attribute names, but rather adding a new 
attribute that only has the shortname. Is there a way to do that may through a 
custom NIS mapping or something like that? Maybe a dynamic schema extension? 
I’ve tried reading through extending the schema, but am currently confused as 
to how to go about it. 

Andy Brook
Sr. Systems Administrator | Center for Research Informatics | University of 
Chicago
T: 773-834-0458 | http://cri.uchicago.edu




This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


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

Re: [Freeipa-users] ipa -v ping lies about the cert database

[Timo Aaltonen]

18.04.2016, 10:14, David Kupka kirjoitti:
> On 15/04/16 15:16, Harald Dunkel wrote:
>> Hi David,
>>
>>> Hello Harri,
>>>
>>> the FreeIPA certificate database is stored in /etc/ipa/nssdb, by
>>> default the permissions are set to:
>>>
>>> $ ls -dl /etc/ipa/nssdb/
>>> drwxr-xr-x. 2 root root 73 Apr 15 14:00 /etc/ipa/nssdb/
>>>
>>> $ ls -l /etc/ipa/nssdb/
>>> total 80
>>> -rw-r--r--. 1 root root 65536 Apr 15 14:00 cert8.db
>>> -rw-r--r--. 1 root root 16384 Apr 15 14:00 key3.db
>>> -rw---. 1 root root40 Apr 15 14:00 pwdfile.txt
>>> -rw-r--r--. 1 root root 16384 Apr 15 14:00 secmod.db
>>>
>>> Please check the permission on your system. If it's different and you
>>> (or system admin) haven't changed it please file a ticket
>>> (https://fedorahosted.org/freeipa/newticket).
>>>
>>
>> Sorry, I should have mentioned that the client runs Debian
>> with freeipa 4.0.5.
>>
>> # ls -al /etc/ipa/
>> total 24
>> drwxr-xr-x   2 root root  4096 Dec 29 08:32 .
>> drwxr-xr-x 190 root root 12288 Apr 15 12:44 ..
>> -rw-r--r--   1 root root  1792 Dec 29 08:32 ca.crt
>> -rw-r--r--   1 root root   194 Dec 29 08:32 default.conf
>>
>>
>> No nssdb. AFAICS only the ipa servers in my lan have a
>> directory /etc/ipa/nssdb (CentOS 7).
>>
>> On the clients I can see a cert8.db in /etc/pki/nssdb.
>> Looking at the time stamp it seems to be related to freeipa.
>>
>> # ls -al /etc/pki/nssdb/
>> total 76
>> drwxr-xr-x 2 root root  4096 Dec 29 08:32 .
>> drwxr-xr-x 3 root root  4096 Dec 28 16:09 ..
>> -rw--- 1 root root 65536 Dec 29 08:32 cert8.db
>> -rw--- 1 root root 16384 Dec 29 08:32 key3.db
>> -rw--- 1 root root 16384 Dec 29 08:32 secmod.db
>>
>> No pwdfile.txt . I would guess the key database has been created
>> with --empty-password.
>>
>> Does this look familiar, or is this misconfigured and weird?
>>
>>
>> Sorry for asking stupid questions, but the setup in my lan is
>> all I have. I have never had a chance to see another freeipa
>> installation. Hope you don't mind?
>>
>>
>> Regards
>> Harri
>>
> 
> Hello Harri,
> actually the version and OS information makes a difference :-)
> 
> Older version of FreeIPA client was using NSSDB in /etc/pki/nssdb, I
> don't recall at what version we switched to /etc/ipa/nssdb but it was
> some time ago.
> 
> I have reproduced the issue on Debian and after changing the access
> rights (# chmod ga+r /etc/pki/nssdb/*) it works for me. ipa command
> needs to access the IPA CA certificate stored there to verify identity
> of FreeIPA server.
> 
> I haven't seen this issue on Fedora so I'm adding Timo who is porting
> FreeIPA on debian. Timo have you met this issue?

The old package used to create /etc/pki/nssdb on postinst, but with 644
permissions so I'm not sure why they have 600 here. 4.1.4 in
experimental migrated to /etc/ipa/nssdb, and I'm about to upload 4.3.1
to unstable this week, which should fix this for good.



-- 
t

-- 
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] howto ldapsearch for disabled/enabled users?

[Martin Kosek]

On 04/15/2016 04:06 PM, Harald Dunkel wrote:
> Hi David,
> 
> On 04/15/16 15:11, David Kupka wrote:
>>
>> Hello Harri,
>>
>> the attribute you're looking for is 'nsaccountlock'. This command should 
>> give you uids of all disabled users:
>>
>> $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=test 
>> "(nsaccountlock=TRUE)" uid
>>
> 
> Thats exactly what I was looking for. For the record: Searching for
> "nsaccountlock=FALSE" did not work. I had to use
> 
> ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=test 
> '(!(nsaccountlock=TRUE))' uid
> 
> instead.

Right, this is because nsaccountlock is not with a user by default, it will be
there after the first time the user is administratively disabled and then 
enabled.

-- 
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 set passwords which never expire ?

[Martin Kosek]

On 04/12/2016 02:10 PM, dbisc...@hrz.uni-kassel.de wrote:
> Hi,
> 
> On Tue, 12 Apr 2016, bahan w wrote:
> 
>> I am using FreeIPA 3.0 and I would like, for specific accounts, to set
>> passwords unexpirables.
>>
>> I tried to set a pwpolicy for this with the option maxage set to 0, but it
>> did not help and the maxage was 0 (password already expired).
>>
>> Is there a way, with this Ipa version, to set passwords unexpirables ?
> 
> it is possible to create a password policy (tab "Policy" in the web interface)
> for a user group of your choice and change the password max lifetime to (e.g.)
> 3650 days = 10 years. That's not exactly "never expiring", but it does the
> trick for me (I use it for LDAP bind users).

Right, this will work as long as the expiration does not go over year 2038:
https://fedorahosted.org/freeipa/ticket/2496

This is the proper RFE to make "0" work:
https://fedorahosted.org/freeipa/ticket/2795
You can add yourself to CC to receive updates on it, it is now scheduled for
the next feature release.

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] Adding FreeIPA to an existing infrastructure

[Martin Kosek]

On 04/12/2016 12:14 PM, Remco Kranenburg wrote:
> Thanks for all the pointers. I'm tentatively moving forward with a CA-less and
> DNS-less IPA server, with Letsencrypt certificates. I think this is also the
> setup that is used by the demo at . Is
> there some documentation about this setup?

I installed this FreeIPA Demo server with Dogtag CA and then used something
like this to setup the root cert:


# do this once before taking snapshot of the VM
dnf install letsencrypt -y

ipa-cacert-manage install le-root-ca.pem -n le-root-ca -t ,,
ipa-certupdate -v

ipa-cacert-manage install le-authority-x1.pem -n le-authority-x1 -t C,,
ipa-certupdate -v


and then generated LE certificate:


# generate CSR
certutil -R -d /etc/httpd/alias/ -k Server-Cert -f /etc/httpd/alias/pwdfile.txt
-s "CN=$(hostname)" --extSAN "dns:$(hostname)" -a -o /root/httpd-csr.pem
openssl req -in /root/httpd-csr.pem -outform der -out /root/httpd-csr.der

# httpd process prevents letsencrypt from working, stop it
service httpd stop

# get a new cert
letsencrypt certonly --csr /root/httpd-csr.der --email ...@redhat.com 
--agree-tos

# remove old cert
certutil -D -d /etc/httpd/alias/ -n Server-Cert
# add the new cert
certutil -A -d /etc/httpd/alias/ -n Server-Cert -t ,, -a -i /root/_cert.pem

# start httpd with the new cert
service httpd start


but you probably do not want this as you are not installing CA piece.

> I'm trying to install a Letsencrypt
> certificate into FreeIPA, but when I run the installation:
> 
> ipa-server-install --http-cert-file cert.pem --http-cert-file privkey.pem
> --dirsrv-cert-file cert.pem --dirsrv-cert-file privkey.pem
> 
> It asks for my "Apache Server private key unlock password", even though the 
> key
> from Letsencrypt is not encrypted with a passphrase. When I give a bogus
> password, it gives me another error:
> 
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe full certificate
> chain is not present in cert.pem, privkey.pem
> 
> Letsencrypt provides me with a few files: cert.pem, chain.pem, fullchain.pem,
> privkey.pem. Even when I also add chain.pem and fullchain.pem, it gives me the
> same error.

CCing JanC, he is the man to help with this one.

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] Username attribute in trusted domain

[Jakub Hrozek]

On Fri, Apr 15, 2016 at 08:01:06PM +, Brook, Andy [CRI] wrote:
> We’re trying to setup FreeIPA to be a good provider of UIDs and GIDs for our 
> mostly RHEL systems. Overall, that works great. The issue I’m running into is 
> that we need to have the same consistent UIDs and GIDs for our Isilon system 
> which serves up both CIFS and NFS. Each user of the Isilon needs to have a 
> UID so that the files are owned properly. The Isilon has a way of getting 
> information from both Active Directory and an associated LDAP server. It gets 
> its list of users and groups from AD, a list of users, UIDs, groups and GIDs 
> from LDAP, and combine accounts that are the same. i.e. ADTEST.LOCAL\abrook 
> and abrook from LDAP will the same user. However, FreeIPA will show abrook(as 
> it sees through the Trust relationship with ADTEST.LOCAL) as 
> abrook@adtest.local instead of abrook, so the 
> Isilon will see them as distinct accounts and won’t merge the information in 
> them. I can’t, as far as I can tell right now, tell the Isilon to see users 
> with @adtest.local as the same user without the domain. I can tell the Isilon 
> to look at a different LDAP attribute as its username, but there is no 
> attribute that has only the username.
> 
> I noticed in the documentation that if I were to do a sync with Active 
> Directory (which isn’t something I want to do), I would get the 
> ntDomainUserID attribute that is the same as the samAccountName. This doesn’t 
> happen with a trust. Is there a way to get that in place with a custom 
> attribute or pull more LDAP attributes from AD?
> 
> Has anyone else run into a situation like this? If so, were you able to 
> rectify that? If so, how?
> 
> We have a ticket open with EMC for the Isilon as well, but want to make sure 
> we’re coming at this from all the angles we can.

I'm sorry, but currently overriding the attribute names for AD trusted
domains is not possible. We are working to make it possible for the next
version, but it's a bit of a stretch goal already, so chances it won't
be ready only for the version after the next one.

What might perhaps help you is that starting with upstream SSSD 1.14
(upstream 7.3), it should be possible to configure SSSD to only print
the shortname and not qualify the users in trusted domains.

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

Re: [Freeipa-users] ipa -v ping lies about the cert database

[David Kupka]

On 15/04/16 15:16, Harald Dunkel wrote:

Hi David,


Hello Harri,

the FreeIPA certificate database is stored in /etc/ipa/nssdb, by default the 
permissions are set to:

$ ls -dl /etc/ipa/nssdb/
drwxr-xr-x. 2 root root 73 Apr 15 14:00 /etc/ipa/nssdb/

$ ls -l /etc/ipa/nssdb/
total 80
-rw-r--r--. 1 root root 65536 Apr 15 14:00 cert8.db
-rw-r--r--. 1 root root 16384 Apr 15 14:00 key3.db
-rw---. 1 root root40 Apr 15 14:00 pwdfile.txt
-rw-r--r--. 1 root root 16384 Apr 15 14:00 secmod.db

Please check the permission on your system. If it's different and you (or 
system admin) haven't changed it please file a ticket 
(https://fedorahosted.org/freeipa/newticket).



Sorry, I should have mentioned that the client runs Debian
with freeipa 4.0.5.

# ls -al /etc/ipa/
total 24
drwxr-xr-x   2 root root  4096 Dec 29 08:32 .
drwxr-xr-x 190 root root 12288 Apr 15 12:44 ..
-rw-r--r--   1 root root  1792 Dec 29 08:32 ca.crt
-rw-r--r--   1 root root   194 Dec 29 08:32 default.conf


No nssdb. AFAICS only the ipa servers in my lan have a
directory /etc/ipa/nssdb (CentOS 7).

On the clients I can see a cert8.db in /etc/pki/nssdb.
Looking at the time stamp it seems to be related to freeipa.

# ls -al /etc/pki/nssdb/
total 76
drwxr-xr-x 2 root root  4096 Dec 29 08:32 .
drwxr-xr-x 3 root root  4096 Dec 28 16:09 ..
-rw--- 1 root root 65536 Dec 29 08:32 cert8.db
-rw--- 1 root root 16384 Dec 29 08:32 key3.db
-rw--- 1 root root 16384 Dec 29 08:32 secmod.db

No pwdfile.txt . I would guess the key database has been created
with --empty-password.

Does this look familiar, or is this misconfigured and weird?


Sorry for asking stupid questions, but the setup in my lan is
all I have. I have never had a chance to see another freeipa
installation. Hope you don't mind?


Regards
Harri



Hello Harri,
actually the version and OS information makes a difference :-)

Older version of FreeIPA client was using NSSDB in /etc/pki/nssdb, I 
don't recall at what version we switched to /etc/ipa/nssdb but it was 
some time ago.


I have reproduced the issue on Debian and after changing the access 
rights (# chmod ga+r /etc/pki/nssdb/*) it works for me. ipa command 
needs to access the IPA CA certificate stored there to verify identity 
of FreeIPA server.


I haven't seen this issue on Fedora so I'm adding Timo who is porting 
FreeIPA on debian. Timo have you met this issue?


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