Re: [Freeipa-users] "Could not locate issuing CA" when querying OCSP responder

[Fraser Tweedale]

On Tue, Jul 26, 2016 at 01:45:19PM +1000, Fraser Tweedale wrote:
> On Mon, Jul 25, 2016 at 05:23:31PM -0500, Anthony Joseph Messina wrote:
> > After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP 
> > responder" 
> > with the following command.  I can confirm certificate with serial 0x14 is 
> > present in the system and is not expired/revoked, etc.  I'm a bit nervous 
> > about the "OCSPServlet: Could not locate issuing CA" in the Dogtag output 
> > below.
> > 
> > # /usr/bin/openssl ocsp \
> >   -issuer /etc/ipa/ca.crt \
> >   -nonce \
> >   -CAfile /etc/ipa/ca.crt \
> >   -url "http://ipa-ca.example.com/ca/ocsp"; \
> >   -serial 0x14
> > 
> > # rpm -q freeipa-server pki-server
> > freeipa-server-4.3.1-1.fc24.x86_64
> > pki-server-10.3.3-1.fc24.noarch
> > 
> Hi Anthony,
> 
> I wrote this code and I think I know what the issue is.  Could you
> please execute `pki-server db-upgrade -v` as root, then try the OCSP
> request again?
> 
> If it works, happy day for you, and for me too because it confirms
> the issue which I must fix :)
> 
On further investigation, what I thought was the problem cannot be
the problem.  No need to follow my earlier suggestion.

But I found (and fixed) something else.  Would you be willing to try
my COPR build[1]?  It contains the linked patch[2] plus whatever is
between your installed pki version and the Dogtag master branch at
a307cf68e91327ddbef4b9d7e2bbd3991354831f.

[1] https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/build/420751/
[2] 
https://fedorahosted.org/pki/attachment/ticket/2420/pki-ftweedal-0128-Fix-CA-OCSP-responder-when-LWCAs-are-not-in-use.patch

Alternatively, you can apply the patch and build Dogtag yourself
(if, e.g., you do not trust my COPR packages, which is fair enough
^_^)

Thanks,
Fraser

-- 
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] "Could not locate issuing CA" when querying OCSP responder

[Fraser Tweedale]

On Mon, Jul 25, 2016 at 05:23:31PM -0500, Anthony Joseph Messina wrote:
> After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP 
> responder" 
> with the following command.  I can confirm certificate with serial 0x14 is 
> present in the system and is not expired/revoked, etc.  I'm a bit nervous 
> about the "OCSPServlet: Could not locate issuing CA" in the Dogtag output 
> below.
> 
> # /usr/bin/openssl ocsp \
>   -issuer /etc/ipa/ca.crt \
>   -nonce \
>   -CAfile /etc/ipa/ca.crt \
>   -url "http://ipa-ca.example.com/ca/ocsp"; \
>   -serial 0x14
> 
> # rpm -q freeipa-server pki-server
> freeipa-server-4.3.1-1.fc24.x86_64
> pki-server-10.3.3-1.fc24.noarch
> 
Hi Anthony,

I wrote this code and I think I know what the issue is.  Could you
please execute `pki-server db-upgrade -v` as root, then try the OCSP
request again?

If it works, happy day for you, and for me too because it confirms
the issue which I must fix :)

Thanks,
Fraser

-- 
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] Deny bind for external LDAP if password is expired

[Prashant Bapat]

In our FreeIPA deployment the clients use pam_nss_ldapd with the "compat"
schema. No ipa-client.

I'm planning to apply the patched ipa_pwd_extop plugin to only 2 of the
replicas (out of 8) where the external app authenticates against IPA's
LDAP. These 2 replicas are more used like readonly. The Web UI where the
users login and change their profile is not on these replicas.

With this LDAP binds are denied to users with expired passwords from the
external app.

Will this setup have any issues, related to replication etc ?

On 11 July 2016 at 19:43, Rob Crittenden  wrote:

> Prashant Bapat wrote:
>
>> I cherrypicked the commit id 3b7d5e7543a074d7d24556cadc6c95be9871cfc6
>> and compiled the ipa-pwd-extop slapi plugin.
>>
>> Now the user is denied bind. But unable to reset the password.
>>
>
> Right, it's a tricky problem which is why it hasn't been resolved yet. You
> have come full circle through the same steps we went through.
>
> rob
>
>
>>
>> On 8 July 2016 at 13:21, Martin Kosek > > wrote:
>>
>> On 07/07/2016 05:19 PM, Prashant Bapat wrote:
>> > Anyone ?!
>> >
>> > On 6 July 2016 at 22:36, Prashant Bapat > 
>> > >> wrote:
>> >
>> > Hi,
>> >
>> > We are using FreeIPA's LDAP as the base for user authentication
>> in a
>> > different application. So far I have created a sysaccount which
>> does the
>> > lookup etc for a user and things are working as expected. I'm
>> even able to
>> > use OTP from the external app.
>> >
>> > One problem I'm struggling to fix is the expired passwords. Is
>> there a way
>> > to deny bind to LDAP only from this application? Obviously the
>> user would
>> > need to go to IPA's web UI and reset his password there.
>> >
>> > I came across this tickethttps://
>> fedorahosted.org/freeipa/ticket/1539 but
>> > looks like this is an old one.
>> >
>> > Thanks.
>> > --Prashant
>>
>> Hello Prashant,
>>
>> https://fedorahosted.org/freeipa/ticket/1539 seems to be the right
>> ticket, if
>> you want users with expired passwords to be denied, but it was not
>> implemented
>> yet. Help welcome!
>>
>> As a workaround, I assume you could simply leverage Kerberos for
>> authentication
>> - it does respect expired passwords. We have advise on how to
>> integrate that to
>> external web applications here:
>>
>> http://www.freeipa.org/page/Web_App_Authentication
>>
>> 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

[Freeipa-users] "Could not locate issuing CA" when querying OCSP responder

[Anthony Joseph Messina]

After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP responder" 
with the following command.  I can confirm certificate with serial 0x14 is 
present in the system and is not expired/revoked, etc.  I'm a bit nervous 
about the "OCSPServlet: Could not locate issuing CA" in the Dogtag output 
below.

# /usr/bin/openssl ocsp \
  -issuer /etc/ipa/ca.crt \
  -nonce \
  -CAfile /etc/ipa/ca.crt \
  -url "http://ipa-ca.example.com/ca/ocsp"; \
  -serial 0x14

# rpm -q freeipa-server pki-server
freeipa-server-4.3.1-1.fc24.x86_64
pki-server-10.3.3-1.fc24.noarch

# tail -f /var/log/pki/pki-tomcat/ca/debug
CMSServlet:service() uri = /ca/ocsp
CMSServlet: caOCSP start to service.
IP: 10.77.79.198
CMSServlet: no authMgrName
CMSServlet: in auditSubjectID
CMSServlet: auditSubjectID auditContext {locale=en_US, ipAddress=10.77.79.198}
CMSServlet auditSubjectID: subjectID: null
CMSServlet: in auditGroupID
CMSServlet: auditGroupID auditContext {locale=en_US, ipAddress=10.77.79.198}
CMSServlet auditGroupID: groupID: null
checkACLS(): ACLEntry expressions= ipaddress=".*"
evaluating expressions: ipaddress=".*"
evaluated expression: ipaddress=".*" to be true
DirAclAuthz: authorization passed
SignedAuditEventFactory: create() message created for eventType=AUTHZ_SUCCESS

In LdapBoundConnFactory::getConn()
masterConn is connected: true
getConn: conn is connected true
getConn: mNumConns now 2
returnConn: mNumConns now 3
SignedAuditEventFactory: create() message created for eventType=ROLE_ASSUME

Servlet Path=/ocsp
RequestURI=/ca/ocsp
PathInfo=null
Method=POST
In LdapBoundConnFactory::getConn()
masterConn is connected: true
getConn: conn is connected true
getConn: mNumConns now 2
returnConn: mNumConns now 3
OCSPServlet: Could not locate issuing CA
CMSServlet.java: renderTemplate
CMSServlet: curDate=Mon Jul 25 17:12:11 CDT 2016 id=caOCSP time=50


-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D  D1C9 FF31 3BDB D9D8 99B6


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] Could not find cert: Signing-Cert : File not found

[Linov Suresh]

We were not sure that Signing-Cert required for LDAP/Apache certificates
renewal. Thank you very much for your update Rob. We are going to renew the
certificates without Signing-Cert.

On Mon, Jul 25, 2016 at 6:08 PM, Rob Crittenden  wrote:

> Linov Suresh wrote:
>
>> We are using CentOS 6.4/FreeIPA 3.0.0
>>
>> LDAP/Apache certificates were expired and when we tried to renew, we
>> found Signing-Cert is missing.
>>
>> # certutil -L -d /etc/httpd/alias -n Signing-Cert certutil: Could not
>> find cert: Signing-Cert : File not found
>>
>> How do we recreate Signing-Cert certificate? We use master-master
>> replica. Please help.
>>
>>
>>
> Only the initial master got a signing cert IIRC. It was used to sign the
> Firefox configuration jar. Are you using this? Recent versions of Firefox
> don't allow this kind of signed jar anymore and it has been dropped
> upstream.
>
> Are you just trying to be thorough or is this causing some real problem?
>
> 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] Could not find cert: Signing-Cert : File not found

[Rob Crittenden]

Linov Suresh wrote:

We are using CentOS 6.4/FreeIPA 3.0.0

LDAP/Apache certificates were expired and when we tried to renew, we
found Signing-Cert is missing.

# certutil -L -d /etc/httpd/alias -n Signing-Cert certutil: Could not
find cert: Signing-Cert : File not found

How do we recreate Signing-Cert certificate? We use master-master
replica. Please help.




Only the initial master got a signing cert IIRC. It was used to sign the 
Firefox configuration jar. Are you using this? Recent versions of 
Firefox don't allow this kind of signed jar anymore and it has been 
dropped upstream.


Are you just trying to be thorough or is this causing some real problem?

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] Could not find cert: Signing-Cert : File not found

[Linov Suresh]

We are using CentOS 6.4/FreeIPA 3.0.0

LDAP/Apache certificates were expired and when we tried to renew, we found
Signing-Cert is missing.

# certutil -L -d /etc/httpd/alias -n Signing-Cert certutil: Could not find
cert: Signing-Cert : File not found

How do we recreate Signing-Cert certificate? We use master-master replica.
Please help.
-- 
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] Cannot renew expired certificates in IPA 4.2

[Rob Crittenden]

lm gnid wrote:

Hello, as in the link bellow, your help will be appreciated!

https://bugzilla.redhat.com/show_bug.cgi?id=1343796


The bug lacks almost all context so I have no idea what you have already 
done.


In any case, the -vvv may be part of the problem, it does not mean verbose.

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] Unable to add CA on an already configured replica

[Rob Crittenden]

pgb205 wrote:

Current topology:
ipa-srv1<->ipa-srv2

ipa-srv1 already has CA installed but *NOT *ipa-srv2.

The reason I would like to add CA on ipa-srv2 is because I want the
setup to ultimately become
ipa-srv2<->ipa-srv2<->ipa-srv3

however I am unable to create gpg replication file on ipa-srv2 (to be
used to establish replication agreement to ipa-srv3)
as I get an error message: /Certificate operation cannot be completed:
Unable to communicate with CMS (Internal Server Error)/
 From what I've found gpg can only be created on replica with CA installed.

to install CA I tried the following command
/ipa-ca-install --skip-conncheck ./replica-info-ipa-srv2.gpg/
This errors out at
/  [8/21]: starting certificate server instance/
/ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart
the Dogtag instance.See the installation log for details./
/  [9/21]: importing CA chain to RA certificate database/
/  [error] RuntimeError: Unable to retrieve CA chain: request failed
with HTTP status 500/
/
systemctl status pki-tomcatd@pki-tomcat.service
/
shows the pki service is running, surprisingly.

but it's still not listed in ipactl status output

further attempts to install are halted with error : CA is already
installed on this system and I have to manually delete everything with:
pkidestroy -s CA -i pki-tomcat
  1003  rm -rf /var/log/pki/pki-tomcat
  1004  rm -rf /etc/sysconfig/pki-tomcat
  1005  rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
  1006  rm -rf /var/lib/pki/pki-tomcat
  1007  rm -rf /etc/pki/pki-tomcat


in error logs the one message that stands out is:
500 internal server error. which repeats multiple times at the end of
log file.


Which log file? You probably want to look at the CA debug log. I'm 
assuming the error is originating in dogtag.



Please suggest on what can be done in this situation.

PS: regarding pkidestroy and pkiremove commands. What is the difference
or does pkidestroy superceeds pkiremove.
Alexander B suggests pkiremove in one of his older posts and 'yum
whatprovides pkiremove' also suggests that it should be available.


Right, pkidestroy replaced pkiremove.

There is no uninstaller for the CA currently. I had started one long ago 
and never finished it. Feel free to open an RFE on it.


Note that it is trickier than just removing files. Depending on where it 
blows up you may need to remove replication agreements too (and entries 
from cn=masters).


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] slow login with freeipa 4.2.0

[Robert Story]

On Mon, 25 Jul 2016 21:23:19 +0530 Rakesh wrote:
RR> Hi,
RR> 
RR> I am facing slow login issue with IPA 4.2.0 version. The login takes around
RR> 18-19s

Any change that it's running on a VM? If so, check your entropy:

 cat /proc/sys/kernel/random/entropy_avail

If it's low (like < 1k), install haveged.


Robert

-- 
Senior Software Engineer @ Parsons


pgperPRYfkDAd.pgp
Description: OpenPGP digital signature
-- 
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] slow login with freeipa 4.2.0

[Jakub Hrozek]

On Mon, Jul 25, 2016 at 09:23:19PM +0530, Rakesh Rajasekharan wrote:
> Hi,
> 
> I am facing slow login issue with IPA 4.2.0 version. The login takes around
> 18-19s
> 
> date;ssh testuser@10.16.32.4
> Mon Jul 25 11:14:54 UTC 2016
> testuser@10.65.32.4's password:
> Last login: Mon Jul 25 11:10:35 2016 from 10.65.16.4
> [testuser@ipa-client-1 :~] date
> Mon Jul 25 11:15:12 UTC 2016

Are you sure the logs correspond to the login attempt? The stamps you
posted are between 11:14:54 and 11:15:12 but the logs below are from a
different time period.

There is a 10 second period in the sssd logs when seemingly nothing
happens.

Does the same delay happen if you su from another non-root account
(ruling out some DNS issues in SSH or similar) ?

-- 
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] listing users, groups and the host they access with sudo rules

[Jakub Hrozek]

On Mon, Jul 25, 2016 at 02:13:49PM +, Stefan Uygur wrote:
> Hi everyone,
> I am using ipa-server-3.0.0-47.el6_7.2.x86_64 on my redhat 6 and I was 
> wondering if there is a way in IPA to list the users, with their group and 
> the hosts they can access along with sudo permissions.
> 
> This is for auditing purposes and IPA doesn't seem to have a functionality 
> that would help rather than performing manual commands to collect all this 
> data, which will require quite time.
> 
> So I was wondering if anyone had similar needs and how they overcome to this 
> issue (knowing that IPA doesn't have auditing part covered).

Not easy per host, but you can install ldbsearch and then check what
sudo rules are fetched by sssd for this host:
# yum install ldb-tools
# ldbsearch -H /var/lib/sss/db/cache_$domain.ldb -b cn=sysdb 
objectClass=sudoRule

-- 
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] Bypass pre-hashed passwords verification

[Rob Crittenden]

Sébastien Julliot wrote:

Looks like I spoke too fast. Using ldappasswd, no problems with ldap
queries.

But kinit rejects my password ..


That is expected. You changed to a pre-hashed password (potentially) so 
how can IPA generate Kerberos credentials? I think ldappasswd working is 
a bug.


IPA is designed to be the central identity source, so it needs to own 
passwords. You can import using an LDAP add pre-hashed passwords that 
can be migrated. You can't do an LDAP mod to set a pre-hashed password, 
even as a passsync mgr.


rob




Le 25/07/2016 à 11:58, Sébastien Julliot a écrit :

Hello Rob,

The indicated method was unsuccessful, but I found another way to do it :)

Here is a summary of my unsuccessful tests :
➜  ~ ipa user-add testuser --first=test --last=user --setattr 
userpassword='{MD5}8UBIfmQu5CpHAAniVJWPrQ=='
---
Utilisateur « testuser » ajouté
---

Now I am able to log as /testuser /. Yet, despite having added admin
as a passSyncManagersDns to cn=ipa_pwd_extop,cn=plugins,cn=config
➜  ~ ldapsearch -LLL -D "cn=Directory Manager" -W -b 
cn=ipa_pwd_extop,cn=plugins,cn=config -s base passsyncmanagersdns
dn: cn=ipa_pwd_extop,cn=plugins,cn=config
passsyncmanagersdns: cn=Directory Manager
passsyncmanagersdns: 
uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr

 I still get an error when trying to set pre-hashed passwords :
➜  ~ cat change_testuser_passwd.ldif
dn: uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr
changetype: modify
replace: userpassword
userpassword:: e01ENX04VUJJZm1RdTVDcEhBQW5pVkpXUHJRPT0=
➜  ~ ldapmodify -D "uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr" 
-W < change_testuser_passwd.ldif
Enter LDAP Password:
modifying entry 
"uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr"
ldap_modify: Constraint violation (19)
 additional info: Pre-Encoded passwords are not valid

However, I noted that using ldappasswd does the job, /even without
having set passSyncManagerDNs.

/It is not as clean as if I could have use freeipa API to change
passwords, but for lack of better, it will do the job.

Le 22/07/2016 à 20:47, Rob Crittenden a écrit :

Sébastien Julliot wrote:

Hi Petr,


Thanks for the documentations. I already had followed the steps from
the
NIS migration page, it works, but does not solve my problem, which
is to
change *already existing users* passwords.

When trying

ipa user-mod testuser --setattr
userpassword='{MD5}G3TITOeG1vuPf/IJyhw8WA=='

I get "Pre-Encoded passwords are not valid"


Look at the first link Petr sent you. There is a password sync
manager setting that should be able to insert pre-hashed passwords.

rob





Le 22/07/2016 à 15:08, Petr Vobornik a écrit :

On 07/22/2016 11:42 AM, Sébastien Julliot wrote:

Hello everyone,

I am currently trying to deploy FreeIPA as the new idm system in my
university but came across a problem I could not solve yet. I need to
bypass the pre-hashed passwords verification, not only on the user
creation.

Due to several constraints, our workflow involves periodically
(once a
day, currently) receiving an ldif file containing the users
up-to-date
informations, (including hashed passwords) and inserting this
informations into the idm. As our goal is to unify users passwords in
the university but do not have access to the higher-level LDAP
directly,
we injected this pre-hashed passwords directly into the LDAP until
today.

Yet, every attempt I made to update users passwords with pre-hashed
passwords failed for now.

First I tried this (migration mode enabled):

➜  ~ ipa user-add testuser --first=test --last=user --setattr
userpassword='{MD5}*'

/*OK*/

➜  ~ kinit testuser

kinit: Generic preauthentication failure while getting initial
credentials

As expected from the documentation, it does not work :p

I then thought about trying to copy the migration plug-in, and change
the way it retrieves users (from LDIF rather than from an online LDAP
server). Since this plugin is able to  But again, event binding as
Directory Manager, the ipa ldap2 backend method add_entry refuses
me (I
tested my code without the userPassword field and the users are
correctly inserted).

Here is my code :

class ldif_importer(ldif.LDIFParser):
 def __init__(self, ldap_backend):
 ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
 self.ldap = ldap_backend

 def handle(self, dn, entry):
 self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))

class my_backend(ipalib.Backend):
 '''Backend to import ldap passwords from ldif'''

 def __init__(self, api):
 ipalib.Backend.__init__(self, api)
 self.ldap = ldap2(self.api)
 self.ldap.connect(bind_dn=DN('cn=Directory Manager'),
bind_pw='***')

 def parse(self):
 importer = ldif_importer(self.ldap)
 importer.parse()

class my_command(ipalib.Command):
 '''Command calling my_backend to import

Re: [Freeipa-users] Insufficient 'write' privilege to the 'userCertificate'

[Rob Crittenden]

mohammad sereshki wrote:

hi
I get below error from "getcert list",would you please help me to solve it?

  ca-error: Server denied our request, giving up: 2100 (RPC failed at
server.  Insufficient access:
Insufficient 'write' privilege to the 'userCertificate' attribute of entry
'krbprincipalname=ldap/ipasrv.example@example.com,cn=services,cn=accounts,dc=example,dc=com'.).


With so many threads on basically the same underlying issue it's 
difficult to tell what works and what doesn't work and what you've done 
to get past various blockers.


What have you done to get past the "Error setting up ccache for local 
"host" service using default keytab" issue, for example?


Generic things to do:

- ipactl status to ensure all services are running
- check /var/log/httpd/error_log for more information on the CA ACL 
issues. You may want to create /etc/ipa/server.conf with these contents:


[global]
debug = True

Then restart httpd and try to reproduce for more verbose output.

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] AD trust with POSIX attributes

[Jan Karásek]

Hi, 

just for the clarification: 

Do I really need IDMU on AD side installed for IPA-AD trust with 
-range-type=ipa-ad-trust-posix ? In W2012 all POSIX attributes are already in 
schema and idrange type can be forced. I just tried to remove IDMU from my AD 
and it's still working. What is the role of IDMU other than allowing to 
autodetect POSIX idrange type via the msSFU30OrderNumber msSFU30MaxUidNumber 
attributes ? 

Regards, 
Jan 


From: "Jan Karásek"  
To: "Justin Stephenson"  
Cc: "Alexander Bokovoy" , freeipa-users@redhat.com 
Sent: Friday, July 22, 2016 3:19:51 PM 
Subject: Re: [Freeipa-users] AD trust with POSIX attributes 

Hi, 

thanks a lot for help guys. It's working now. I can successfully read POSIX 
attributes from AD. 

Just now I'am storring uidNumber, gidNumber, gecos, loginShell and 
unixHomeDirectory in AD. 

I have trouble with homedir. It's using subdomain_homedir from sssd.conf and 
not reflecting the value of unixHomeDirectory attribute. 

Is there any way to use value from AD not from subdomain_homedir template for 
this parameter ? 

Regards, 
Jan 

From: "Justin Stephenson"  
To: "Jan Karásek" , "Alexander Bokovoy" 
 
Cc: freeipa-users@redhat.com 
Sent: Thursday, July 21, 2016 3:54:25 PM 
Subject: Re: [Freeipa-users] AD trust with POSIX attributes 



Hello, 

You should remove the following from sssd.conf: 



[domain/example.tt] 
debug_level = 7 
ldap_id_mapping = False 
id_provider = ad 

With the AD trust configuration, you do not need to specify any additional 
domain because IPA will contact AD across the trust using the external and 
POSIX groups you created during the trust setup. 

Once done try restarting sssd and removing the /var/lib/sss/db/* cache 

Kind regards, 
Justin Stephenson 

On 07/21/2016 07:56 AM, Jan Karásek wrote: 

BQ_BEGIN

Thank you. 

Now I have IDMU installed and when creating trust, IPA is correctly 
autodetecting the range type: 

Range name: EXAMPLE.TT_id_range 
First Posix ID of the range: 1 
Number of IDs in the range: 20 
Domain SID of the trusted domain: S-1-5-21-4123312533-990676102-3576722756 
Range type: Active Directory trust range with POSIX attributes 

When asking for uid of the AD user: 

[root@ipa1 sssd]# id us...@example.tt 
uid=1392001119( us...@example.tt ) gid=1392001119( us...@example.tt ) 
groups=1392001119( us...@example.tt ),1392000513(domain us...@example.tt 
),97907(external_users) 


... so ID-mapping is still in action. 

According to doc: 

To use existing POSIX attributes, two things must be configured: 


* 
The POSIX attributes must be published to Active Directory's global catalog. - 
done with uidNumber, gidNumber 

* 
ID mapping ( ldap_id_mapping in the Active Directory domain entry) must be 
disabled in SSSD. - done 

Here is my sssd.conf from IPA server. Is there anything else I should do to 
switch off ID-mapping ? 

[domain/a.example.tt] 
debug_level = 7 
cache_credentials = True 
krb5_store_password_if_offline = True 
ipa_domain = a.example.tt 
id_provider = ipa 
auth_provider = ipa 
access_provider = ipa 
ipa_hostname = ipa1.a.example.tt 
chpass_provider = ipa 
ipa_server = ipa1.a.example.tt 
ipa_server_mode = True 
ldap_tls_cacert = /etc/ipa/ca.crt 
#subdomain_inherit = ldap_user_principal 
#ldap_user_principal = nosuchattribute 

[domain/example.tt] 
debug_level = 7 
ldap_id_mapping = False 
id_provider = ad 

[sssd] 
services = nss, sudo, pam, ssh 
config_file_version = 2 
domains = a.example.tt, example.tt 

[nss] 
#debug_level = 5 
#homedir_substring = /home 
enum_cache_timeout = 2 
entry_negative_timeout = 2 


[pam] 
#debug_level = 5 
[sudo] 

[autofs] 

[ssh] 
#debug_level = 4 
[pac] 

#debug_level = 4 
[ifp] 


Regards, 
Jan 

From: "Alexander Bokovoy"  
To: "Jan Karásek"  
Cc: "Justin Stephenson"  , freeipa-users@redhat.com 
Sent: Wednesday, July 20, 2016 6:06:29 PM 
Subject: Re: [Freeipa-users] AD trust with POSIX attributes 

On Wed, 20 Jul 2016, Jan Karásek wrote: 
>Hi, 
> 
>thank you. 
> 
>ldapsearch reply: 
> 
>search: 2 
>result: 32 No such object 
>matchedDN: CN=RpcServices,CN=System,DC=rwe,DC=tt 
>text: 208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best 
>match of: 
>'CN=RpcServices,CN=System,DC=rwe,DC=tt' 
> 
>actually when I look under the CN=RpcServices,CN=System,DC=rwe,DC=tt - it is 
>empty. 
> 
>Do I missed to set something on the AD site ? 
Yes. You need to setup IDMU. However, in Windows Server 2016 Microsoft 
removed IDMU tools. The LDAP schema will stay but there will 
be no means to visually edit POSIX attributes. 

https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/
 



> 
>Thanks, 
>Jan 
> 
> 
> 
> 
> 
> 
> 
>From: "Justin Stephenson"  
>To: "Jan Karásek"  
>Cc: freeipa-users@redhat.com 
>Sent: Wednesday, July 20, 2016 4:09:02 PM 
>Subject: Re: [Freeipa-users] AD trust with POSIX attributes 
> 
> 
> 
>These attributes should be available from port 389 and 

Re: [Freeipa-users] vaults and service accounts

[Martin Basti]

On 25.07.2016 16:22, Anthony Clark wrote:
I wondered about that, but the docs specifically say public key, and 
the command line option to "ipa vault-add" is "--public-key"


From "ipa vault-add --help"

  --public-key=BYTESVault public key
  --public-key-file=STR   File containing the vault public key

So I hope you can understand my confusion ;)

Can anyone else speak to whether the newer versions of the vault code 
is any different?


Thank you, Martin!


Yeah sorry, I meant public key, private key is used for decipher.

My point was just not to use certificate.

Martin



On Mon, Jul 25, 2016 at 4:32 AM, Martin Basti > wrote:




On 24.07.2016 16:33, Anthony Clark wrote:

Hello All,

I have a crazy notion of storing a host's SSH private keys in a
ipa vault, so that a rebuilt host can use the same keys.

I'm on CentOS 7.2 and I'm using the RPMs available in the
standard centos base repository, so I'm constrained to version
1.0 vaults.  I'm using this page:

http://www.freeipa.org/page/V4/Password_Vault_1.0#Provisioning_service_vault_password_for_service_instance

I'm trying these following steps but running into trouble:

ipa service-add ssh/test01.dev.redacted.net


certutil -N -d testcertdb

certutil -R -d testcertdb -a -g 2048 -s
'CN=test01.dev.redacted.net
,O=DEV.REDACTED.NET
'


ipa-getcert request -r -f testsshd01-cert.pem -k
testsshd01-key.pem -K
ssh/test01.dev.redacted@dev.redacted.net


ipa vault-add testsshd02 --service
ssh/test01.dev.redacted@dev.redacted.net
 --type
asymmetric --public-key-file testsshd01-cert.pem

the last command gives me "ipa: ERROR: invalid
'ipavaultpublickey': Invalid or unsupported vault public key:
Could not unserialize key data."

Is there a preferred way to create a public key for asymmetric
encryption for a service vault?

Thanks,

Anthony Clark




Hello,
I suspect you should use just private key, not certificate

https://en.wikibooks.org/wiki/Cryptography/Generate_a_keypair_using_OpenSSL

Regards,
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] vaults and service accounts

[Anthony Clark]

I wondered about that, but the docs specifically say public key, and the
command line option to "ipa vault-add" is "--public-key"

>From "ipa vault-add --help"

  --public-key=BYTESVault public key
  --public-key-file=STR   File containing the vault public key

So I hope you can understand my confusion ;)

Can anyone else speak to whether the newer versions of the vault code is
any different?

Thank you, Martin!


On Mon, Jul 25, 2016 at 4:32 AM, Martin Basti  wrote:

>
>
> On 24.07.2016 16:33, Anthony Clark wrote:
>
> Hello All,
>
> I have a crazy notion of storing a host's SSH private keys in a ipa vault,
> so that a rebuilt host can use the same keys.
>
> I'm on CentOS 7.2 and I'm using the RPMs available in the standard centos
> base repository, so I'm constrained to version 1.0 vaults.  I'm using this
> page:
> http://www.freeipa.org/page/V4/Password_Vault_1.0#Provisioning_service_vault_password_for_service_instance
>
> I'm trying these following steps but running into trouble:
>
> ipa service-add ssh/test01.dev.redacted.net
>
> certutil -N -d testcertdb
>
> certutil -R -d testcertdb -a -g 2048 -s 'CN=test01.dev.redacted.net,O=
> DEV.REDACTED.NET'
> 
>
> ipa-getcert request -r -f testsshd01-cert.pem -k testsshd01-key.pem -K ssh/
> test01.dev.redacted@dev.redacted.net
>
> ipa vault-add testsshd02 --service ssh/
> 
> test01.dev.redacted@dev.redacted.net --type asymmetric
> --public-key-file testsshd01-cert.pem
>
> the last command gives me "ipa: ERROR: invalid 'ipavaultpublickey':
> Invalid or unsupported vault public key: Could not unserialize key data."
>
> Is there a preferred way to create a public key for asymmetric encryption
> for a service vault?
>
> Thanks,
>
> Anthony Clark
>
>
>
> Hello,
> I suspect you should use just private key, not certificate
>
> https://en.wikibooks.org/wiki/Cryptography/Generate_a_keypair_using_OpenSSL
>
> Regards,
> 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

[Freeipa-users] listing users, groups and the host they access with sudo rules

[Stefan Uygur]

Hi everyone,
I am using ipa-server-3.0.0-47.el6_7.2.x86_64 on my redhat 6 and I was 
wondering if there is a way in IPA to list the users, with their group and the 
hosts they can access along with sudo permissions.

This is for auditing purposes and IPA doesn't seem to have a functionality that 
would help rather than performing manual commands to collect all this data, 
which will require quite time.

So I was wondering if anyone had similar needs and how they overcome to this 
issue (knowing that IPA doesn't have auditing part covered).

Thanks

Stefan
-- 
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] Replicating users/groups from AD

[Petr Spacek]

On 25.7.2016 15:30, Simo Sorce wrote:
> On Mon, 2016-07-25 at 08:24 -0500, Alston, David wrote:
>> Greetings!
>>
>>  Yes, I had been hoping there would be a way to incorporate domain
>> trusts between Active Directory and FreeIPA while the clients relying
>> on these for identity management shared the same DNS domain (eg.
>> linux.company.com and windows.company.com).  It sounds like that isn't
>> going to happen.
> 
> These are two different domains, as long as linuc.company.com is used
> only by freeIPA this configuration is already supported via trust
> relationship.

Let me add that there are workarounds for other cases as well:
http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/

Petr^2 Spacek


> 
>>  Account replication seems like another way for Active Directory
>> users to be able to login to servers to use the same username/password
>> for logging in.  It wouldn't have SSO, but at least a user would be
>> able to use the same username/password everywhere.  Replicating user
>> accounts from an external AD/LDAP server seems to be built-in, at the
>> moment.  There aren't any plans to take that away, is there?  Ideally,
>> I'd want a two way sync so that password changes and user group
>> changes are replicated back to AD as well.
> 
> winsync is not being further developed but we have no plans to take it
> away.
> 
> Simo.
> 
>> --David Alston
>>
>> -Original Message-
>> From: Simo Sorce [mailto:s...@redhat.com] 
>> Sent: Friday, July 22, 2016 10:49 AM
>> To: Alston, David
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] Replicating users/groups from AD
>>
>> On Fri, 2016-07-22 at 09:59 -0500, Alston, David wrote:
>>> Greetings!
>>
>>>
>>
>>>  I realize that FreeIPA is supposed to be setup as master of its 
>>
>>> own domain, but are there any plans to continue the account 
>>
>>> replication functionality that has already been in FreeIPA?  I had 
>>
>>> heard rumor that it would be possible to have FreeIPA and Active 
>>
>>> Directory coexist in the same domain in some release in the future.
>>
>>> Am I waiting for a feature that will never come?
>>
>>
>> Hi David,
>> in order to respond to your question an idea of what are your expectations 
>> would is needed.
>>
>> If by Domain you mean "AD Domain or Kerberos Realm", the answer is no, they 
>> will never coexists.
>>
>> If by Domain you mean DNS Domain read then FreeIPA can work in the same 
>> domain as AD but only if you do not care for them interacting (at the 
>> kerberos level, no trusts, no SSO).
>> You can basically have only one association between a DNS domain and a 
>> Realm, and a DNS domain is either going to be associated to the AD Domain 
>> server or to the IPA Domain.
>>
>> Synchronization, however is a completely unrelated topic, and I can't give 
>> you an answer on that side as I do not understand how it would
>> relate to the coexistence of FreeIPA and AD in a single DNS domain.   
>>
>> 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] Replicating users/groups from AD

[Simo Sorce]

On Mon, 2016-07-25 at 08:24 -0500, Alston, David wrote:
> Greetings!
> 
>  Yes, I had been hoping there would be a way to incorporate domain
> trusts between Active Directory and FreeIPA while the clients relying
> on these for identity management shared the same DNS domain (eg.
> linux.company.com and windows.company.com).  It sounds like that isn't
> going to happen.

These are two different domains, as long as linuc.company.com is used
only by freeIPA this configuration is already supported via trust
relationship.

>  Account replication seems like another way for Active Directory
> users to be able to login to servers to use the same username/password
> for logging in.  It wouldn't have SSO, but at least a user would be
> able to use the same username/password everywhere.  Replicating user
> accounts from an external AD/LDAP server seems to be built-in, at the
> moment.  There aren't any plans to take that away, is there?  Ideally,
> I'd want a two way sync so that password changes and user group
> changes are replicated back to AD as well.

winsync is not being further developed but we have no plans to take it
away.

Simo.

> --David Alston
> 
> -Original Message-
> From: Simo Sorce [mailto:s...@redhat.com] 
> Sent: Friday, July 22, 2016 10:49 AM
> To: Alston, David
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Replicating users/groups from AD
> 
> On Fri, 2016-07-22 at 09:59 -0500, Alston, David wrote:
> > Greetings!
> 
> > 
> 
> >  I realize that FreeIPA is supposed to be setup as master of its 
> 
> > own domain, but are there any plans to continue the account 
> 
> > replication functionality that has already been in FreeIPA?  I had 
> 
> > heard rumor that it would be possible to have FreeIPA and Active 
> 
> > Directory coexist in the same domain in some release in the future.
> 
> > Am I waiting for a feature that will never come?
> 
> 
> Hi David,
> in order to respond to your question an idea of what are your expectations 
> would is needed.
> 
> If by Domain you mean "AD Domain or Kerberos Realm", the answer is no, they 
> will never coexists.
> 
> If by Domain you mean DNS Domain read then FreeIPA can work in the same 
> domain as AD but only if you do not care for them interacting (at the 
> kerberos level, no trusts, no SSO).
> You can basically have only one association between a DNS domain and a Realm, 
> and a DNS domain is either going to be associated to the AD Domain server or 
> to the IPA Domain.
> 
> Synchronization, however is a completely unrelated topic, and I can't give 
> you an answer on that side as I do not understand how it would
> relate to the coexistence of FreeIPA and AD in a single DNS domain.   
> 
> Simo.
> 
> --
> Simo Sorce * Red Hat, Inc * New York
> 


-- 
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] Freeipa and FQDN requirement

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Ilan Green wrote:

Thanks,
The issue per customer is having loads of legacy applications
programmed to use short host names - it will be cumbersome to fix it

What Petr asked about is to not host IPA server on the same machine as
those legacy apps. Have IPA servers separate from legacy apps.

There is no need to rename all legacy hosts but there is also no need to
have IPA master hosted on the same machine as any of those legacy hosts.
--
/ 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] Replicating users/groups from AD

[Alston, David]

Greetings!

 Yes, I had been hoping there would be a way to incorporate domain trusts 
between Active Directory and FreeIPA while the clients relying on these for 
identity management shared the same DNS domain (eg. linux.company.com and 
windows.company.com).  It sounds like that isn't going to happen.

 Account replication seems like another way for Active Directory users to 
be able to login to servers to use the same username/password for logging in.  
It wouldn't have SSO, but at least a user would be able to use the same 
username/password everywhere.  Replicating user accounts from an external 
AD/LDAP server seems to be built-in, at the moment.  There aren't any plans to 
take that away, is there?  Ideally, I'd want a two way sync so that password 
changes and user group changes are replicated back to AD as well.

--David Alston

-Original Message-
From: Simo Sorce [mailto:s...@redhat.com] 
Sent: Friday, July 22, 2016 10:49 AM
To: Alston, David
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Replicating users/groups from AD

On Fri, 2016-07-22 at 09:59 -0500, Alston, David wrote:
> Greetings!
> 
>  I realize that FreeIPA is supposed to be setup as master of its 
> own domain, but are there any plans to continue the account 
> replication functionality that has already been in FreeIPA?  I had 
> heard rumor that it would be possible to have FreeIPA and Active 
> Directory coexist in the same domain in some release in the future.
> Am I waiting for a feature that will never come?

Hi David,
in order to respond to your question an idea of what are your expectations 
would is needed.

If by Domain you mean "AD Domain or Kerberos Realm", the answer is no, they 
will never coexists.

If by Domain you mean DNS Domain read then FreeIPA can work in the same domain 
as AD but only if you do not care for them interacting (at the kerberos level, 
no trusts, no SSO).
You can basically have only one association between a DNS domain and a Realm, 
and a DNS domain is either going to be associated to the AD Domain server or to 
the IPA Domain.

Synchronization, however is a completely unrelated topic, and I can't give you 
an answer on that side as I do not understand how it would
relate to the coexistence of FreeIPA and AD in a single DNS domain.   

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] Freeipa and FQDN requirement

[Ilan Green]

Thanks, 
The issue per customer is having loads of legacy applications programmed to use 
short host names - it will be cumbersome to fix it 

Ilan Green 
Senior Technical Account Manager - EMEA 
Red Hat 
Mobile (+972) 52 3403218 
email: igr...@redhat.com 

- Original Message -

> From: "Petr Spacek" 
> To: freeipa-users@redhat.com
> Sent: Monday, July 25, 2016 4:01:39 PM
> Subject: Re: [Freeipa-users] Freeipa and FQDN requirement

> On 25.7.2016 14:49, Ilan Green wrote:
> > Hello,
> > Customer wants to switch between the IPA server FQDN and short name in
> > /etc/hosts (having the short name first) post IPA install?
> >
> > Can anyone please confirm that the suggestions & reservations listed by
> > Simo Sorce in the following thread still apply - i.e. no RFE was ever
> > applied yet?
> > https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00079
> >
> > mainly:
> > https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00104
> > https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00105

> This might or might not work, we do not test this scenario.

> In any case it goes directly against procedures in official docs:

> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs

> ... so do not be surprised if things break.

> In general we strongly recommend to use a dedicated machine for IdM server
> for
> security reasons. There should be no technical reason not to use FQDN
> hostname
> for a dedicated VM as the requirement for short names as hostname usually
> comes from crappy applications.

> --
> Petr^2 Spacek

> --
> 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] Freeipa and FQDN requirement

[Petr Spacek]

On 25.7.2016 14:49, Ilan Green wrote:
> Hello, 
> Customer wants to switch between the IPA server FQDN and short name in 
> /etc/hosts (having the short name first) post IPA install? 
> 
> Can anyone please confirm that the suggestions & reservations listed by Simo 
> Sorce in the following thread still apply - i.e. no RFE was ever applied yet? 
> https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00079 
> 
> mainly: 
> https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00104 
> https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00105 

This might or might not work, we do not test this scenario.

In any case it goes directly against procedures in official docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs

... so do not be surprised if things break.


In general we strongly recommend to use a dedicated machine for IdM server for
security reasons. There should be no technical reason not to use FQDN hostname
for a dedicated VM as the requirement for short names as hostname usually
comes from crappy applications.

-- 
Petr^2 Spacek

-- 
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] Bypass pre-hashed passwords verification

[Petr Spacek]

On 25.7.2016 14:00, Sébastien Julliot wrote:
> Looks like I spoke too fast. Using ldappasswd, no problems with ldap
> queries.
> 
> But kinit rejects my password ..

AFAIK this works only for LDAP ADD operation. Rob, do you remember?

Petr^2 Spacek

> Le 25/07/2016 à 11:58, Sébastien Julliot a écrit :
>> Hello Rob,
>>
>> The indicated method was unsuccessful, but I found another way to do it :)
>>
>> Here is a summary of my unsuccessful tests :
>> ➜  ~ ipa user-add testuser --first=test --last=user --setattr 
>> userpassword='{MD5}8UBIfmQu5CpHAAniVJWPrQ=='
>> ---
>> Utilisateur « testuser » ajouté
>> ---
>>
>> Now I am able to log as /testuser /. Yet, despite having added admin
>> as a passSyncManagersDns to cn=ipa_pwd_extop,cn=plugins,cn=config
>> ➜  ~ ldapsearch -LLL -D "cn=Directory Manager" -W -b 
>> cn=ipa_pwd_extop,cn=plugins,cn=config -s base passsyncmanagersdns
>> dn: cn=ipa_pwd_extop,cn=plugins,cn=config
>> passsyncmanagersdns: cn=Directory Manager
>> passsyncmanagersdns: 
>> uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr
>>
>>  I still get an error when trying to set pre-hashed passwords :
>> ➜  ~ cat change_testuser_passwd.ldif
>> dn: uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr
>> changetype: modify
>> replace: userpassword
>> userpassword:: e01ENX04VUJJZm1RdTVDcEhBQW5pVkpXUHJRPT0=
>> ➜  ~ ldapmodify -D 
>> "uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr" -W < 
>> change_testuser_passwd.ldif
>> Enter LDAP Password:
>> modifying entry 
>> "uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr"
>> ldap_modify: Constraint violation (19)
>> additional info: Pre-Encoded passwords are not valid
>>
>> However, I noted that using ldappasswd does the job, /even without
>> having set passSyncManagerDNs.
>>
>> /It is not as clean as if I could have use freeipa API to change
>> passwords, but for lack of better, it will do the job.
>>
>> Le 22/07/2016 à 20:47, Rob Crittenden a écrit :
>>> Sébastien Julliot wrote:
 Hi Petr,


 Thanks for the documentations. I already had followed the steps from
 the
 NIS migration page, it works, but does not solve my problem, which
 is to
 change *already existing users* passwords.

 When trying

 ipa user-mod testuser --setattr
 userpassword='{MD5}G3TITOeG1vuPf/IJyhw8WA=='

 I get "Pre-Encoded passwords are not valid"
>>>
>>> Look at the first link Petr sent you. There is a password sync
>>> manager setting that should be able to insert pre-hashed passwords.
>>>
>>> rob
>>>



 Le 22/07/2016 à 15:08, Petr Vobornik a écrit :
> On 07/22/2016 11:42 AM, Sébastien Julliot wrote:
>> Hello everyone,
>>
>> I am currently trying to deploy FreeIPA as the new idm system in my
>> university but came across a problem I could not solve yet. I need to
>> bypass the pre-hashed passwords verification, not only on the user
>> creation.
>>
>> Due to several constraints, our workflow involves periodically
>> (once a
>> day, currently) receiving an ldif file containing the users
>> up-to-date
>> informations, (including hashed passwords) and inserting this
>> informations into the idm. As our goal is to unify users passwords in
>> the university but do not have access to the higher-level LDAP
>> directly,
>> we injected this pre-hashed passwords directly into the LDAP until
>> today.
>>
>> Yet, every attempt I made to update users passwords with pre-hashed
>> passwords failed for now.
>>
>> First I tried this (migration mode enabled):
>>
>> ➜  ~ ipa user-add testuser --first=test --last=user --setattr
>> userpassword='{MD5}*'
>>
>> /*OK*/
>>
>> ➜  ~ kinit testuser
>>
>> kinit: Generic preauthentication failure while getting initial
>> credentials
>>
>> As expected from the documentation, it does not work :p
>>
>> I then thought about trying to copy the migration plug-in, and change
>> the way it retrieves users (from LDIF rather than from an online LDAP
>> server). Since this plugin is able to  But again, event binding as
>> Directory Manager, the ipa ldap2 backend method add_entry refuses
>> me (I
>> tested my code without the userPassword field and the users are
>> correctly inserted).
>>
>> Here is my code :
>>
>> class ldif_importer(ldif.LDIFParser):
>>  def __init__(self, ldap_backend):
>>  ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
>>  self.ldap = ldap_backend
>>
>>  def handle(self, dn, entry):
>>  self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))
>>
>> class my_backend(ipalib.Backend):
>>  '''Backend to import ldap passwords from ldif'''
>>
>>  def __init__(self, api):
>>  ipal

[Freeipa-users] Freeipa and FQDN requirement

[Ilan Green]

Hello, 
Customer wants to switch between the IPA server FQDN and short name in 
/etc/hosts (having the short name first) post IPA install? 

Can anyone please confirm that the suggestions & reservations listed by Simo 
Sorce in the following thread still apply - i.e. no RFE was ever applied yet? 
https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00079 

mainly: 
https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00104 
https://www.redhat.com/archives/freeipa-users/2014-August/thread.html#00105 


Thanks, 

Ilan Green 
Senior Technical Account Manager - EMEA 
Red Hat 
Mobile (+972) 52 3403218 
email: igr...@redhat.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] Bypass pre-hashed passwords verification

[Sébastien Julliot]

Looks like I spoke too fast. Using ldappasswd, no problems with ldap
queries.

But kinit rejects my password ..


Le 25/07/2016 à 11:58, Sébastien Julliot a écrit :
> Hello Rob,
>
> The indicated method was unsuccessful, but I found another way to do it :)
>
> Here is a summary of my unsuccessful tests :
> ➜  ~ ipa user-add testuser --first=test --last=user --setattr 
> userpassword='{MD5}8UBIfmQu5CpHAAniVJWPrQ=='
> ---
> Utilisateur « testuser » ajouté
> ---
>
> Now I am able to log as /testuser /. Yet, despite having added admin
> as a passSyncManagersDns to cn=ipa_pwd_extop,cn=plugins,cn=config
> ➜  ~ ldapsearch -LLL -D "cn=Directory Manager" -W -b 
> cn=ipa_pwd_extop,cn=plugins,cn=config -s base passsyncmanagersdns
> dn: cn=ipa_pwd_extop,cn=plugins,cn=config
> passsyncmanagersdns: cn=Directory Manager
> passsyncmanagersdns: 
> uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr
>
>  I still get an error when trying to set pre-hashed passwords :
> ➜  ~ cat change_testuser_passwd.ldif
> dn: uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr
> changetype: modify
> replace: userpassword
> userpassword:: e01ENX04VUJJZm1RdTVDcEhBQW5pVkpXUHJRPT0=
> ➜  ~ ldapmodify -D 
> "uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr" -W < 
> change_testuser_passwd.ldif
> Enter LDAP Password:
> modifying entry 
> "uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr"
> ldap_modify: Constraint violation (19)
> additional info: Pre-Encoded passwords are not valid
>
> However, I noted that using ldappasswd does the job, /even without
> having set passSyncManagerDNs.
>
> /It is not as clean as if I could have use freeipa API to change
> passwords, but for lack of better, it will do the job.
>
> Le 22/07/2016 à 20:47, Rob Crittenden a écrit :
>> Sébastien Julliot wrote:
>>> Hi Petr,
>>>
>>>
>>> Thanks for the documentations. I already had followed the steps from
>>> the
>>> NIS migration page, it works, but does not solve my problem, which
>>> is to
>>> change *already existing users* passwords.
>>>
>>> When trying
>>>
>>> ipa user-mod testuser --setattr
>>> userpassword='{MD5}G3TITOeG1vuPf/IJyhw8WA=='
>>>
>>> I get "Pre-Encoded passwords are not valid"
>>
>> Look at the first link Petr sent you. There is a password sync
>> manager setting that should be able to insert pre-hashed passwords.
>>
>> rob
>>
>>>
>>>
>>>
>>> Le 22/07/2016 à 15:08, Petr Vobornik a écrit :
 On 07/22/2016 11:42 AM, Sébastien Julliot wrote:
> Hello everyone,
>
> I am currently trying to deploy FreeIPA as the new idm system in my
> university but came across a problem I could not solve yet. I need to
> bypass the pre-hashed passwords verification, not only on the user
> creation.
>
> Due to several constraints, our workflow involves periodically
> (once a
> day, currently) receiving an ldif file containing the users
> up-to-date
> informations, (including hashed passwords) and inserting this
> informations into the idm. As our goal is to unify users passwords in
> the university but do not have access to the higher-level LDAP
> directly,
> we injected this pre-hashed passwords directly into the LDAP until
> today.
>
> Yet, every attempt I made to update users passwords with pre-hashed
> passwords failed for now.
>
> First I tried this (migration mode enabled):
>
> ➜  ~ ipa user-add testuser --first=test --last=user --setattr
> userpassword='{MD5}*'
>
> /*OK*/
>
> ➜  ~ kinit testuser
>
> kinit: Generic preauthentication failure while getting initial
> credentials
>
> As expected from the documentation, it does not work :p
>
> I then thought about trying to copy the migration plug-in, and change
> the way it retrieves users (from LDIF rather than from an online LDAP
> server). Since this plugin is able to  But again, event binding as
> Directory Manager, the ipa ldap2 backend method add_entry refuses
> me (I
> tested my code without the userPassword field and the users are
> correctly inserted).
>
> Here is my code :
>
> class ldif_importer(ldif.LDIFParser):
>  def __init__(self, ldap_backend):
>  ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
>  self.ldap = ldap_backend
>
>  def handle(self, dn, entry):
>  self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))
>
> class my_backend(ipalib.Backend):
>  '''Backend to import ldap passwords from ldif'''
>
>  def __init__(self, api):
>  ipalib.Backend.__init__(self, api)
>  self.ldap = ldap2(self.api)
>  self.ldap.connect(bind_dn=DN('cn=Directory Manager'),
> bind_pw='***')
>
>  def parse(self):
>  importer = ldif_importer(self.ldap)
>   

Re: [Freeipa-users] Bypass pre-hashed passwords verification

[Sébastien Julliot]

Hello Rob,

The indicated method was unsuccessful, but I found another way to do it :)

Here is a summary of my unsuccessful tests :

➜  ~ ipa user-add testuser --first=test --last=user --setattr 
userpassword='{MD5}8UBIfmQu5CpHAAniVJWPrQ=='
---
Utilisateur « testuser » ajouté
---


Now I am able to log as /testuser /. Yet, despite having added admin as
a passSyncManagersDns to cn=ipa_pwd_extop,cn=plugins,cn=config

➜  ~ ldapsearch -LLL -D "cn=Directory Manager" -W -b 
cn=ipa_pwd_extop,cn=plugins,cn=config -s base passsyncmanagersdns
dn: cn=ipa_pwd_extop,cn=plugins,cn=config
passsyncmanagersdns: cn=Directory Manager
passsyncmanagersdns: 
uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr

 I still get an error when trying to set pre-hashed passwords :

➜  ~ cat change_testuser_passwd.ldif

dn: uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr

changetype: modify

replace: userpassword

userpassword:: e01ENX04VUJJZm1RdTVDcEhBQW5pVkpXUHJRPT0=

➜  ~ ldapmodify -D 
"uid=admin,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr" -W < 
change_testuser_passwd.ldif

Enter LDAP Password:

modifying entry 
"uid=testuser,cn=users,cn=accounts,dc=ljll,dc=math,dc=upmc,dc=fr"

ldap_modify: Constraint violation (19)

additional info: Pre-Encoded passwords are not valid


However, I noted that using ldappasswd does the job, /even without
having set passSyncManagerDNs.

/It is not as clean as if I could have use freeipa API to change
passwords, but for lack of better, it will do the job.

Le 22/07/2016 à 20:47, Rob Crittenden a écrit :
> Sébastien Julliot wrote:
>> Hi Petr,
>>
>>
>> Thanks for the documentations. I already had followed the steps from the
>> NIS migration page, it works, but does not solve my problem, which is to
>> change *already existing users* passwords.
>>
>> When trying
>>
>> ipa user-mod testuser --setattr
>> userpassword='{MD5}G3TITOeG1vuPf/IJyhw8WA=='
>>
>> I get "Pre-Encoded passwords are not valid"
>
> Look at the first link Petr sent you. There is a password sync manager
> setting that should be able to insert pre-hashed passwords.
>
> rob
>
>>
>>
>>
>> Le 22/07/2016 à 15:08, Petr Vobornik a écrit :
>>> On 07/22/2016 11:42 AM, Sébastien Julliot wrote:
 Hello everyone,

 I am currently trying to deploy FreeIPA as the new idm system in my
 university but came across a problem I could not solve yet. I need to
 bypass the pre-hashed passwords verification, not only on the user
 creation.

 Due to several constraints, our workflow involves periodically (once a
 day, currently) receiving an ldif file containing the users up-to-date
 informations, (including hashed passwords) and inserting this
 informations into the idm. As our goal is to unify users passwords in
 the university but do not have access to the higher-level LDAP
 directly,
 we injected this pre-hashed passwords directly into the LDAP until
 today.

 Yet, every attempt I made to update users passwords with pre-hashed
 passwords failed for now.

 First I tried this (migration mode enabled):

 ➜  ~ ipa user-add testuser --first=test --last=user --setattr
 userpassword='{MD5}*'

 /*OK*/

 ➜  ~ kinit testuser

 kinit: Generic preauthentication failure while getting initial
 credentials

 As expected from the documentation, it does not work :p

 I then thought about trying to copy the migration plug-in, and change
 the way it retrieves users (from LDIF rather than from an online LDAP
 server). Since this plugin is able to  But again, event binding as
 Directory Manager, the ipa ldap2 backend method add_entry refuses
 me (I
 tested my code without the userPassword field and the users are
 correctly inserted).

 Here is my code :

 class ldif_importer(ldif.LDIFParser):
  def __init__(self, ldap_backend):
  ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
  self.ldap = ldap_backend

  def handle(self, dn, entry):
  self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))

 class my_backend(ipalib.Backend):
  '''Backend to import ldap passwords from ldif'''

  def __init__(self, api):
  ipalib.Backend.__init__(self, api)
  self.ldap = ldap2(self.api)
  self.ldap.connect(bind_dn=DN('cn=Directory Manager'),
 bind_pw='***')

  def parse(self):
  importer = ldif_importer(self.ldap)
  importer.parse()

 class my_command(ipalib.Command):
  '''Command calling my_backend to import passwords from ldif'''

  def execute(self, **options):
  '''Implemented against my_backend'''
  self.Backend.my_backend.parse()
  return {'result': 'everything OK'}

Re: [Freeipa-users] vaults and service accounts

[Martin Basti]

On 24.07.2016 16:33, Anthony Clark wrote:

Hello All,

I have a crazy notion of storing a host's SSH private keys in a ipa 
vault, so that a rebuilt host can use the same keys.


I'm on CentOS 7.2 and I'm using the RPMs available in the standard 
centos base repository, so I'm constrained to version 1.0 vaults.  I'm 
using this page: 
http://www.freeipa.org/page/V4/Password_Vault_1.0#Provisioning_service_vault_password_for_service_instance


I'm trying these following steps but running into trouble:

ipa service-add ssh/test01.dev.redacted.net 



certutil -N -d testcertdb

certutil -R -d testcertdb -a -g 2048 -s 'CN=test01.dev.redacted.net 
,O=DEV.REDACTED.NET 
'



ipa-getcert request -r -f testsshd01-cert.pem -k testsshd01-key.pem -K 
ssh/test01.dev.redacted@dev.redacted.net 



ipa vault-add testsshd02 --service 
ssh/test01.dev.redacted@dev.redacted.net 
 --type asymmetric 
--public-key-file testsshd01-cert.pem


the last command gives me "ipa: ERROR: invalid 'ipavaultpublickey': 
Invalid or unsupported vault public key: Could not unserialize key data."


Is there a preferred way to create a public key for asymmetric 
encryption for a service vault?


Thanks,

Anthony Clark




Hello,
I suspect you should use just private key, not certificate

https://en.wikibooks.org/wiki/Cryptography/Generate_a_keypair_using_OpenSSL

Regards,
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] Unable to add CA on an already configured replica

[Martin Basti]

On 22.07.2016 20:17, pgb205 wrote:

Current topology:
ipa-srv1<->ipa-srv2

ipa-srv1 already has CA installed but *NOT *ipa-srv2.

The reason I would like to add CA on ipa-srv2 is because I want the 
setup to ultimately become

ipa-srv2<->ipa-srv2<->ipa-srv3

however I am unable to create gpg replication file on ipa-srv2 (to be 
used to establish replication agreement to ipa-srv3)
as I get an error message: /Certificate operation cannot be completed: 
Unable to communicate with CMS (Internal Server Error)/
From what I've found gpg can only be created on replica with CA 
installed.


to install CA I tried the following command
/ipa-ca-install --skip-conncheck ./replica-info-ipa-srv2.gpg/
This errors out at
/  [8/21]: starting certificate server instance/
/ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to 
restart the Dogtag instance.See the installation log for details./

/  [9/21]: importing CA chain to RA certificate database/
/  [error] RuntimeError: Unable to retrieve CA chain: request failed 
with HTTP status 500/


/Hello,
can you please check /var/log/pki/pki-tomcat/ca/debug for more specific 
errors?


Regards,
Martin

/

/
systemctl status pki-tomcatd@pki-tomcat.service
/
shows the pki service is running, surprisingly.

but it's still not listed in ipactl status output

further attempts to install are halted with error : CA is already 
installed on this system and I have to manually delete everything with:

pkidestroy -s CA -i pki-tomcat
 1003  rm -rf /var/log/pki/pki-tomcat
 1004  rm -rf /etc/sysconfig/pki-tomcat
 1005  rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
 1006  rm -rf /var/lib/pki/pki-tomcat
 1007  rm -rf /etc/pki/pki-tomcat


in error logs the one message that stands out is:
500 internal server error. which repeats multiple times at the end of 
log file.


Please suggest on what can be done in this situation.

PS: regarding pkidestroy and pkiremove commands. What is the 
difference or does pkidestroy superceeds pkiremove.
Alexander B suggests pkiremove in one of his older posts and 'yum 
whatprovides pkiremove' also suggests that it should be available.





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