Re: [Freeipa-users] Login Troubles with Centos7 and external users (4.2.0-15.0.1.el7.centos.17)

[Alexander Bokovoy]

On Wed, 03 Aug 2016, Jake wrote:

Hello All,
I'm new to FreeIPA and am having some issues with my endpoints.

First attempts to login as usern...@legacy.example.org always fail with:
Logs on client:
sshd[3771]: Invalid user usern...@legacy.example.org from 192.168.1.123
sshd[3771]: input_userauth_request: invalid user usern...@legacy.example.org 
[preauth]

[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][name=username]
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null).
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed.
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success)
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1003][1][name=NOUSER]
[sssd[be[ipa.example.com]]] [sysdb_get_real_name] (0x0040): 
sysdb_search_object_by_uuid did not return a single result.
[sssd[be[ipa.example.com]]] [groups_by_user_done] (0x0040): Failed to 
canonicalize name, using [NOUSER].
[sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
Object not found, ending request
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 3,0,Account info lookup failed
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765]
[sssd[be[ipa.example.com]]] [sdap_get_users_done] (0x0040): Failed to retrieve 
users
[sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
Object not found, ending request
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 3,0,Account info lookup failed
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765]
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null).
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed.
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success)
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765]
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null).
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed.
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success)
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765]
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null).
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed.
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success)

running the command 'getent password usern...@legacy.example.org' on the ipa 
server works fine

Logs from server:
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][name=username]
[sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain 
lookup failed, will try to reset sudomain..
[sssd[be[ipa.example.com]]] [child_sig_handler] (0x0100): child [26269] 
finished successfully.
[sssd[be[ipa.example.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup 
of service 'legacy.example.org' as 'neutral'
[sssd[be[ipa.example.com]]] [fo_set_port_status] (0x0100): Marking port 0 of 
server '(no name)' as 'neutral'
[sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): 
ipa_get_*_acct request failed: [1432158262]: Subdomain is inactive.
[sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): 
ipa_get_*_acct request failed: 1432158262
[sssd[be[ipa.example.com]]] [ipa_account_info_error_text] (0x0020): Bug: 
dp_error is OK on failed request
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 3,1432158262,Account info lookup failed


Stuff:
(4) IPA Masters at ipa.example.com
(4) root domain controllers in example.com
(4) child domain controllers in new.example.com
(4) second domain in legacy.example.org

There is a (1) way trust between ipa.example.com and example.com (forest trust)
There is a (1) way trust between ipa.example.com and legacy.example.org (forest 
with single domain)
There is a (2) way trust between example.com and legacy.example.org (forest 
transitive trust)

Was the trust between example.com and legacy.example.org established
before establishing trust between IPA and any of those forest roots?

Can you check in the trust properties on AD side for both forest roots,
what is the state of name suffix routing to IPA domain? It should be
enabled for both.

If not, you need to solve conflicts.

There is a document

Re: [Freeipa-users] Login Troubles with Centos7 and external users (4.2.0-15.0.1.el7.centos.17)

[Jake]

Thanks Jakub,
turns out 'getent password usern...@legacy.example.org' only works on 1 of the 
4 ipa servers (the one I created the domain trust with).

I re-ran ipa-adtrust-install on them and no change, is there a similar post I 
can follow to correct these & retrace my steps or does the trust need 
configured on each.

Thank You,
-Jake

- Original Message -
From: "Jakub Hrozek" 
To: "Jake" 
Cc: freeipa-users@redhat.com
Sent: Wednesday, August 3, 2016 3:51:26 PM
Subject: Re: [Freeipa-users] Login Troubles with Centos7 and external users 
(4.2.0-15.0.1.el7.centos.17)

> On 3 Aug 2016, at 20:14, Jake  wrote:
> 
> Hello All,
> I'm new to FreeIPA and am having some issues with my endpoints.
> 
> First attempts to login as usern...@legacy.example.org always fail with:
> Logs on client:
> sshd[3771]: Invalid user usern...@legacy.example.org from 192.168.1.123
> sshd[3771]: input_userauth_request: invalid user usern...@legacy.example.org 
> [preauth]
> 
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][name=username]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1003][1][name=NOUSER]
> [sssd[be[ipa.example.com]]] [sysdb_get_real_name] (0x0040): 
> sysdb_search_object_by_uuid did not return a single result.
> [sssd[be[ipa.example.com]]] [groups_by_user_done] (0x0040): Failed to 
> canonicalize name, using [NOUSER].
> [sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
> Object not found, ending request
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 3,0,Account info lookup failed
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [sdap_get_users_done] (0x0040): Failed to 
> retrieve users
> [sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
> Object not found, ending request
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 3,0,Account info lookup failed
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.

OK, here looking up an ID failed. It would be interesting to see what happened 
with this lookup on the server. Normally I try to truncate the logs on both the 
server and the client, then run:
date; id $username; date
that allows to correlate logs from the server and the client and better 
pinpoint what fails..

> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> 
> running the command 'getent password usern...@legacy.example.org' on the ipa 
> server works fine
> 
> Logs from server:
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][name=username]
> [sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain 
> lookup failed, will try to reset sudomain..

This log line doesn't look so successful :-) but as long as the server returns 
'something' from the cache, the client should grab it

> [sssd[be[ipa.example.com]]] [child_sig_handler] (0x0100): child [26269] 
> finished successfully.
> [sssd[be[ipa.example.com]]] [set_srv_data_status] (0x0100): Marking SRV 
> lookup of service 'legacy.example.org' as 'neutral'
> [sssd[be[ipa.example.com]]] [fo_set_port_status] (0x0100): Marking port 0 of 
> server '(no name)' as 'neutral'
> [sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): 
> ipa_get_*_acct request fai

Re: [Freeipa-users] FreeIPA and AD trusts on the same DNS domain

[Alston, David]

Greetings!

>> 2. Active Directory must never know anything about a DNS domain 
>> freeipa.company.com (I'm not sure why)
> Correct because if that happened then AD considers the whole subdomain as 
> part of its realm and trust routing will not work.

Doesn't that mean that we have to have the FreeIPA servers on their own DNS 
domain again?  So we can't have linux-server.company.com and 
windows-server.company.com (managed by FreeIPA and AD respectively) because 
there has to be a SOA for .company.com somewhere and that is already managed by 
AD (in our environment).

 Also, thanks for your other answers.  They were very helpful :^)

--David Alston


-Original Message-
From: Simo Sorce [mailto:s...@redhat.com] 
Sent: Wednesday, August 03, 2016 2:13 PM
To: Alston, David
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA and AD trusts on the same DNS domain

On Wed, 2016-08-03 at 13:52 -0500, Alston, David wrote:
> Greetings!
> 
>  That sounds like great news!   Just to make sure I understand correctly..
> 
> 1. Any server managed by FreeIPA must NEVER have had a computer object 
> associated with them in AD?  (even if it has now been deleted)
No, what a random server does or has done is irrelevant in this sense, but see 
later, for caveats.

> 2. Active Directory must never know anything about a DNS domain 
> freeipa.company.com (I'm not sure why)
Correct because if that happened then AD considers the whole subdomain as part 
of its realm and trust routing will not work.

> 3. My linux servers being managed by FreeIPA can still have the DNS 
> domain company.com (instead of servername.freeipa.company.com)
Although the strict answer is yes, if you put a linux server joined to freeIPA 
in the AD DNS Domain then Single Sign On from Windows users will not work, as 
AD will consider all request for tickets to those servers as requests for 
itself and will never return referrals to the freeIPA KDCs for those TGS 
requests, so clients will not be able to get tickets for those servers. 

> 4. Single Signon to the Linux servers using AD credentials will still 
> work

No, see above.

> 5. (BONUS) I could even let AD trust user accounts created in FreeIPA?

Not clear what you mean here. If you mean that IPA user accounts can operate in 
the Windows domain, the answer is technicaly yes, although because we do not 
expose (yet) a Global Catalog to the Windows AD servers, it will be hard to set 
ACLs on the Windows side to actually authorize freeIPA users to login to AD 
managed computers (it can probably be done via CLI, but not through AD 
administrative UIs).
We plan to fix this in the near future by providing a GC service.


HTH,
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] Login Troubles with Centos7 and external users (4.2.0-15.0.1.el7.centos.17)

[Jakub Hrozek]

> On 3 Aug 2016, at 20:14, Jake  wrote:
> 
> Hello All,
> I'm new to FreeIPA and am having some issues with my endpoints.
> 
> First attempts to login as usern...@legacy.example.org always fail with:
> Logs on client:
> sshd[3771]: Invalid user usern...@legacy.example.org from 192.168.1.123
> sshd[3771]: input_userauth_request: invalid user usern...@legacy.example.org 
> [preauth]
> 
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][name=username]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1003][1][name=NOUSER]
> [sssd[be[ipa.example.com]]] [sysdb_get_real_name] (0x0040): 
> sysdb_search_object_by_uuid did not return a single result.
> [sssd[be[ipa.example.com]]] [groups_by_user_done] (0x0040): Failed to 
> canonicalize name, using [NOUSER].
> [sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
> Object not found, ending request
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 3,0,Account info lookup failed
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [sdap_get_users_done] (0x0040): Failed to 
> retrieve users
> [sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
> Object not found, ending request
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 3,0,Account info lookup failed
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][idnumber=1644425765]
> [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
> ldap_extended_operation result: No such object(32), (null).
> [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
> request failed.

OK, here looking up an ID failed. It would be interesting to see what happened 
with this lookup on the server. Normally I try to truncate the logs on both the 
server and the client, then run:
date; id $username; date
that allows to correlate logs from the server and the client and better 
pinpoint what fails..

> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 0,0,Success (Success)
> 
> running the command 'getent password usern...@legacy.example.org' on the ipa 
> server works fine
> 
> Logs from server:
> [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
> [0x1001][1][name=username]
> [sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain 
> lookup failed, will try to reset sudomain..

This log line doesn't look so successful :-) but as long as the server returns 
'something' from the cache, the client should grab it

> [sssd[be[ipa.example.com]]] [child_sig_handler] (0x0100): child [26269] 
> finished successfully.
> [sssd[be[ipa.example.com]]] [set_srv_data_status] (0x0100): Marking SRV 
> lookup of service 'legacy.example.org' as 'neutral'
> [sssd[be[ipa.example.com]]] [fo_set_port_status] (0x0100): Marking port 0 of 
> server '(no name)' as 'neutral'
> [sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): 
> ipa_get_*_acct request failed: [1432158262]: Subdomain is inactive.
> [sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): 
> ipa_get_*_acct request failed: 1432158262
> [sssd[be[ipa.example.com]]] [ipa_account_info_error_text] (0x0020): Bug: 
> dp_error is OK on failed request
> [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
> Returned 3,1432158262,Account info lookup failed
> 
> 
> Stuff:
> (4) IPA Masters at ipa.example.com
> (4) root domain controllers in example.com
> (4) child domain controllers in new.example.com
> (4) second domain in legacy.example

Re: [Freeipa-users] FreeIPA and AD trusts on the same DNS domain

[Simo Sorce]

On Wed, 2016-08-03 at 13:52 -0500, Alston, David wrote:
> Greetings!
> 
>  That sounds like great news!   Just to make sure I understand correctly..
> 
> 1. Any server managed by FreeIPA must NEVER have had a computer object 
> associated with them in AD?  (even if it has now been deleted)
No, what a random server does or has done is irrelevant in this sense,
but see later, for caveats.

> 2. Active Directory must never know anything about a DNS domain 
> freeipa.company.com (I'm not sure why)
Correct because if that happened then AD considers the whole subdomain
as part of its realm and trust routing will not work.

> 3. My linux servers being managed by FreeIPA can still have the DNS domain 
> company.com (instead of servername.freeipa.company.com)
Although the strict answer is yes, if you put a linux server joined to
freeIPA in the AD DNS Domain then Single Sign On from Windows users will
not work, as AD will consider all request for tickets to those servers
as requests for itself and will never return referrals to the freeIPA
KDCs for those TGS requests, so clients will not be able to get tickets
for those servers. 

> 4. Single Signon to the Linux servers using AD credentials will still work

No, see above.

> 5. (BONUS) I could even let AD trust user accounts created in FreeIPA?

Not clear what you mean here. If you mean that IPA user accounts can
operate in the Windows domain, the answer is technicaly yes, although
because we do not expose (yet) a Global Catalog to the Windows AD
servers, it will be hard to set ACLs on the Windows side to actually
authorize freeIPA users to login to AD managed computers (it can
probably be done via CLI, but not through AD administrative UIs).
We plan to fix this in the near future by providing a GC service.


HTH,
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 AD trusts on the same DNS domain

[Alston, David]

Greetings!

 That sounds like great news!   Just to make sure I understand correctly..

1. Any server managed by FreeIPA must NEVER have had a computer object 
associated with them in AD?  (even if it has now been deleted)
2. Active Directory must never know anything about a DNS domain 
freeipa.company.com (I'm not sure why)
3. My linux servers being managed by FreeIPA can still have the DNS domain 
company.com (instead of servername.freeipa.company.com)
4. Single Signon to the Linux servers using AD credentials will still work
5. (BONUS) I could even let AD trust user accounts created in FreeIPA?

--David Alston

-Original Message-
From: Simo Sorce [mailto:s...@redhat.com] 
Sent: Wednesday, August 03, 2016 1:28 PM
To: Alston, David
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA and AD trusts on the same DNS domain

On Wed, 2016-08-03 at 13:24 -0500, Alston, David wrote:
> Greetings!
> 
>  Everyone seems to say that you can't have a domain trust across two 
> Kerberos realms (FreeIPA and Active Directory) if the hosts share the same 
> DNS domain.
> 
>  Hadoop seems to do this just fine, though.  I'm in the process of 
> helping someone setup a trust between the Kerberos realms 
> HADOOP.COMPANY.COM  and  COMPANY.COM and all of the servers use the 
> company.com DNS domain. (see 
> http://www.cloudera.com/documentation/archive/cdh/4-x/4-5-0/CDH4-Secur
> ity-Guide/cdh4sg_topic_15.html)
> 
>  This seems to be standard practice for setting up hadoop clusters.  Why 
> wouldn't setting up a one-way trust so that FREEIPA.COMPANY.COM trusts 
> COMPANY.COM (with all involved servers having the "company.com" DNS domain)?  
> As I understand it, the Kerberos realm FreeIPA uses can be specified during 
> the initial setup and it doesn't have to match the domain.
> 
> --David Alston
> --
> 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

You can have a Realm named COMPANY.COM (AD) and a Realm named 
FREEIPA.COMPANY.COM (IPA), as long as the AD Servers never had computer objects 
or subdomains in the DNS domain freeipa.company.com in it.

If that's the case you can create a 1 way or 2 way trust between the 2 forests 
without issues.

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 AD trusts on the same DNS domain

[Simo Sorce]

On Wed, 2016-08-03 at 13:24 -0500, Alston, David wrote:
> Greetings!
> 
>  Everyone seems to say that you can't have a domain trust across two 
> Kerberos realms (FreeIPA and Active Directory) if the hosts share the same 
> DNS domain.
> 
>  Hadoop seems to do this just fine, though.  I'm in the process of 
> helping someone setup a trust between the Kerberos realms HADOOP.COMPANY.COM  
> and  COMPANY.COM and all of the servers use the company.com DNS domain. (see 
> http://www.cloudera.com/documentation/archive/cdh/4-x/4-5-0/CDH4-Security-Guide/cdh4sg_topic_15.html)
> 
>  This seems to be standard practice for setting up hadoop clusters.  Why 
> wouldn't setting up a one-way trust so that FREEIPA.COMPANY.COM trusts 
> COMPANY.COM (with all involved servers having the "company.com" DNS domain)?  
> As I understand it, the Kerberos realm FreeIPA uses can be specified during 
> the initial setup and it doesn't have to match the domain.
> 
> --David Alston
> -- 
> 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

You can have a Realm named COMPANY.COM (AD) and a Realm named
FREEIPA.COMPANY.COM (IPA), as long as the AD Servers never had computer
objects or subdomains in the DNS domain freeipa.company.com in it.

If that's the case you can create a 1 way or 2 way trust between the 2
forests without issues.

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] Third Party Certificate

[Ian Harding]

On 08/02/2016 08:19 AM, Florence Blanc-Renaud wrote:
> On 08/02/2016 03:17 PM, Ian Harding wrote:
>> Hello!
>>
>> I have been using FreeIPA for a while in our network with 6 replicas and
>> it's been working great.  I seem to have made a wee mistake though and
>> I'd appreciate some help.
>>
>> I did this:
>>
>> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
>>
>> on one server because I had a new cert for our internal domain and I
>> thought it might be nice to use the same cert for all our internal web
>> services.
>>
>> It worked fine but now when I'm on that server I get
>> SEC_ERROR_UNTRUSTED_ISSUER when I run ipa commands.  Is there any way I
>> can roll this back, or make it work as is?
>>
>> Thanks!
>>
>> -Ian
>>
> Hi Ian,
> 
> if the certificate that you installed was issued by a CA not known by
> IPA (let's call him the issuer), then you need to add this issuer cert
> first using:
> ipa-cacert-manage install  -n nickname -t C,,
> kinit admin
> ipa-certupdate
> 
> You can check that the issuer cert is properly installed in
> /etc/httpd/alias and /etc/ipa/nssdb with:
> certutil -L -d /etc/httpd/alias
> certutil -L -d /etc/ipa/nssdb
> where it should appear with C,, flags
> 
> Hope this helps,
> Flo.
> 

I seem to have created a problem here.

First some background.

freeipa-sea.bpt.rocks suffered ldap database corruption on a messy
reboot.  I tried to delete it from the freeipa ecosystem but did a poor
job, then rebuilt it with the same name and IP address.

Replication issues ensued.

I chose this inopportune time to install the ssl certificate as
described above.

I have spent today deleting old replication agreements and
reestablishing them which seems to have worked on most of the replicas.

However I see this now on most of them

[root@bpt-nyc1-nfs ianh]# ipa-csreplica-manage list
Directory Manager password:

seattlenfs.bpt.rocks: master
bpt-nyc1-nfs.bpt.rocks: master
freeipa-sea.bpt.rocks: CA not configured
bellevuenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: master
edinburghnfs.bpt.rocks: master
fremontnis.bpt.rocks: master

Is this related to the original deletion or the subsequent addition of
the certificate?   I installed the replicas with their own CA.

I have added the certificate root to the replicas as mentioned above.

Thanks!

-- 
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] FreeIPA and AD trusts on the same DNS domain

[Alston, David]

Greetings!

 Everyone seems to say that you can't have a domain trust across two 
Kerberos realms (FreeIPA and Active Directory) if the hosts share the same DNS 
domain.

 Hadoop seems to do this just fine, though.  I'm in the process of helping 
someone setup a trust between the Kerberos realms HADOOP.COMPANY.COM  and  
COMPANY.COM and all of the servers use the company.com DNS domain. (see 
http://www.cloudera.com/documentation/archive/cdh/4-x/4-5-0/CDH4-Security-Guide/cdh4sg_topic_15.html)

 This seems to be standard practice for setting up hadoop clusters.  Why 
wouldn't setting up a one-way trust so that FREEIPA.COMPANY.COM trusts 
COMPANY.COM (with all involved servers having the "company.com" DNS domain)?  
As I understand it, the Kerberos realm FreeIPA uses can be specified during the 
initial setup and it doesn't have to match the domain.

--David Alston
-- 
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] Login Troubles with Centos7 and external users (4.2.0-15.0.1.el7.centos.17)

[Jake]

Hello All, 
I'm new to FreeIPA and am having some issues with my endpoints. 

First attempts to login as usern...@legacy.example.org always fail with: 
Logs on client: 
sshd[3771]: Invalid user usern...@legacy.example.org from 192.168.1.123 
sshd[3771]: input_userauth_request: invalid user usern...@legacy.example.org 
[preauth] 

[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][name=username] 
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null). 
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed. 
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success) 
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1003][1][name=NOUSER] 
[sssd[be[ipa.example.com]]] [sysdb_get_real_name] (0x0040): 
sysdb_search_object_by_uuid did not return a single result. 
[sssd[be[ipa.example.com]]] [groups_by_user_done] (0x0040): Failed to 
canonicalize name, using [NOUSER]. 
[sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
Object not found, ending request 
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 3,0,Account info lookup failed 
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765] 
[sssd[be[ipa.example.com]]] [sdap_get_users_done] (0x0040): Failed to retrieve 
users 
[sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): 
Object not found, ending request 
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 3,0,Account info lookup failed 
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765] 
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null). 
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed. 
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success) 
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765] 
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null). 
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed. 
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success) 
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][idnumber=1644425765] 
[sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
ldap_extended_operation result: No such object(32), (null). 
[sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request 
failed. 
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 0,0,Success (Success) 

running the command 'getent password usern...@legacy.example.org' on the ipa 
server works fine 

Logs from server: 
[sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for 
[0x1001][1][name=username] 
[sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain 
lookup failed, will try to reset sudomain.. 
[sssd[be[ipa.example.com]]] [child_sig_handler] (0x0100): child [26269] 
finished successfully. 
[sssd[be[ipa.example.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup 
of service 'legacy.example.org' as 'neutral' 
[sssd[be[ipa.example.com]]] [fo_set_port_status] (0x0100): Marking port 0 of 
server '(no name)' as 'neutral' 
[sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): 
ipa_get_*_acct request failed: [1432158262]: Subdomain is inactive. 
[sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): 
ipa_get_*_acct request failed: 1432158262 
[sssd[be[ipa.example.com]]] [ipa_account_info_error_text] (0x0020): Bug: 
dp_error is OK on failed request 
[sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. 
Returned 3,1432158262,Account info lookup failed 


Stuff: 
(4) IPA Masters at ipa.example.com 
(4) root domain controllers in example.com 
(4) child domain controllers in new.example.com 
(4) second domain in legacy.example.org 

There is a (1) way trust between ipa.example.com and example.com (forest trust) 
There is a (1) way trust between ipa.example.com and legacy.example.org (forest 
with single domain) 
There is a (2) way trust between example.com and legacy.example.org (forest 
transitive trust) 

Users are in legacy.example.org and new.example.com 
User Computers are in new .example.com 
Linux Servers are in ipa.example.com as hostname linux.example.com 

Gist for kbr5.conf 
https://gist.github.com/JakeDEvans/8e787bc5751d3d0e8f3b18943d63f00b 
Gist for sssd.conf 
https://gist.github.com/JakeDEvans/ed34098b96b6e061095da85e1db58d70 

Re: [Freeipa-users] IPAv3.0 WebUI User Population

[Simo Sorce]

On Wed, 2016-08-03 at 13:03 -0500, Brad Cesarone wrote:
> Does it just need the objectclass? Does it care if there are any
> values assigned to the attributes underneath the posixaccount object
> class?

The posixAccount, as per schema, requires:
- cn
- uid
- uidNumber
- gidNumber
- homeDirectory

Note also that your warranty is void if you start adding random objects
in the FreeIPA cn=accounts container :-)

Simo.

> 
> 
> 
> -Martin Basti  wrote: - 
> To: Brad Cesarone 
> From: Martin Basti 
> Date: 08/03/2016 01:01PM
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population
> 
> 
> 
> 
> 
> 
> On 03.08.2016 19:58, Brad Cesarone wrote:
> 
> 
> Hi Martin
>  
> I've been playing with adding objectclasses to the non-posix user. I have so 
> far added inetuser, ipaobject, ipasshuser. He started with top, person, 
> organizationalPerson, inetOrgPerson and two custom classes. 
> 
> You need this 'posixaccount' according the source code of IPA 3.3.0
> 
> Martin
> 
>  
> Nothing came up in /var/log/dirsrv/slapd-*/access when running the search but 
> in the /var/log/httpd/error_log there is the following entry:  
> user_find{u'', whoami=False, all=False, raw=False, version='2.49', 
> no_members=False, pkey_only=False}: SUCCESS
>  
> The command outputted 
> --
> 0 users matched
> -
> 
> Number of Entries Returned 0
> 
>  
> Thanks
> -Brad
> 
> -Martin Basti  wrote: - 
> To: Brad Cesarone , freeipa-users@redhat.com
> From: Martin Basti 
> Date: 08/03/2016 12:44PM
> Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population
> 
> 
> 
> 
> 
> 
> On 03.08.2016 18:38, Brad Cesarone wrote:
> 
> Hello All
>  
> I'm trying to figure out how the webUI populates the user page. I have a mix 
> of posix users and non-posix users.
> The non-posix users were added using an LDIF and imported fine. I am able to 
> view them using ipa user-show, ldapsearch, and if I navigate to them using 
> the user details URL they show up. Groups are also able to find the non-posix 
> users and verify membership. I am just unable to use ipa user-find or see 
> them in the users page.
> 
> Hello, I'm afraid you may miss an objectclass in imported users.
> 
> Can you please run ipa user-find, and provide SRCH filter from 
> /var/log/dirsrv/slapd-*/access  (I hope this is the right path on RHEL6.8)
> 
> Then please provide all objectclasses that have a random imported user
> 
> regards
> Martin
> 
>  
> I apologize if this has already been answered, I tried google-fu and it 
> didn't return anything useful.
> Using IPA 3.0 on Redhat 6.8
>  
> Thanks
> -Brad
> 
>  
> -- 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


-- 
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] IPAv3.0 WebUI User Population

[Martin Basti]

On 03.08.2016 20:03, Brad Cesarone wrote:
Does it just need the objectclass? Does it care if there are any 
values assigned to the attributes underneath the posixaccount object 
class?




All must attributes are required.

objectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Standard LDAP 
objectclass' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ 
homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) 
X-ORIGIN 'RFC 2307' )


Martin



-Martin Basti  wrote: -
To: Brad Cesarone 
From: Martin Basti 
Date: 08/03/2016 01:01PM
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population



On 03.08.2016 19:58, Brad Cesarone wrote:


Hi Martin
I've been playing with adding objectclasses to the non-posix user. I 
have so far added inetuser, ipaobject, ipasshuser. He started with 
top, person, organizationalPerson, inetOrgPerson and two custom classes.


You need this 'posixaccount' according the source code of IPA 3.3.0

Martin
Nothing came up in /var/log/dirsrv/slapd-*/access when running the 
search but in the /var/log/httpd/error_log there is the 
following entry:  user_find{u'', whoami=False, all=False, 
raw=False, version='2.49', no_members=False, pkey_only=False}: SUCCESS

The command outputted
--
0 users matched
-

Number of Entries Returned 0

Thanks
-Brad

-Martin Basti  wrote: -
To: Brad Cesarone , freeipa-users@redhat.com
From: Martin Basti 
Date: 08/03/2016 12:44PM
Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population



On 03.08.2016 18:38, Brad Cesarone wrote:

Hello All
I'm trying to figure out how the webUI populates the user page. I 
have a mix of posix users and non-posix users.
The non-posix users were added using an LDIF and imported fine. I am 
able to view them using ipa user-show, ldapsearch, and if I navigate 
to them using the user details URL they show up. Groups are also 
able to find the non-posix users and verify membership. I am just 
unable to use ipa user-find or see them in the users page.


Hello, I'm afraid you may miss an objectclass in imported users.

Can you please run ipa user-find, and provide SRCH filter from 
/var/log/dirsrv/slapd-*/access (I hope this is the right path on RHEL6.8)


Then please provide all objectclasses that have a random imported user

regards
Martin
I apologize if this has already been answered, I tried google-fu and 
it didn't return anything useful.

Using IPA 3.0 on Redhat 6.8
Thanks
-Brad








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

 I understand now that attempts to replicate user accounts from AD into 
FreeIPA isn't going to be getting any updates any time soon because the library 
being used to sync is basically defunct.

 I'll start a new thread with my question about FreeIPA Kerberos realm 
trusting an AD Kerberos realm while on the same DNS domain.  I've come across 
some new information that I'd like to check with ya'll.

 Thanks, everyone, for your answers!


--David Alston


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Alston, David
Sent: Monday, July 25, 2016 8:24 AM
To: Simo Sorce
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Replicating users/groups from AD

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

-- 
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] Deleted Replica Problems

[Ian Harding]

I deleted a replica that had a corrupted ldap database and it caused
some problems.  I'm now getting the dreaded

[root@edinburghnfs ianh]# ipa-replica-manage connect freeipa-sea.bpt.rocks
Connection unsuccessful: freeipa-sea.bpt.rocks is an IPA Server, but it
might be unknown, foreign or previously deleted one.

I had to go around and remove old replication agreements from the other
replicas, but then they could connect again.  This one, and another, I
am not able to do that with.  They were initially created with
freeipa-sea as their master.

I assume I run ipa-server-install --uninstall on edinburghnis, then
reinstall to fix?

There's always an error about having to "Manually remove" the ldap
database.  What's the best way to do that?

Thanks!


- Ian

-- 
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] IPAv3.0 WebUI User Population

[Brad Cesarone]

Does it just need the objectclass? Does it care if there are any values 
assigned to the attributes underneath the posixaccount object class?




-Martin Basti  wrote: - 
To: Brad Cesarone 
From: Martin Basti 
Date: 08/03/2016 01:01PM
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population






On 03.08.2016 19:58, Brad Cesarone wrote:


Hi Martin
 
I've been playing with adding objectclasses to the non-posix user. I have so 
far added inetuser, ipaobject, ipasshuser. He started with top, person, 
organizationalPerson, inetOrgPerson and two custom classes. 

You need this 'posixaccount' according the source code of IPA 3.3.0

Martin

 
Nothing came up in /var/log/dirsrv/slapd-*/access when running the search but 
in the /var/log/httpd/error_log there is the following entry:  
user_find{u'', whoami=False, all=False, raw=False, version='2.49', 
no_members=False, pkey_only=False}: SUCCESS
 
The command outputted 
--
0 users matched
-

Number of Entries Returned 0

 
Thanks
-Brad

-Martin Basti  wrote: - 
To: Brad Cesarone , freeipa-users@redhat.com
From: Martin Basti 
Date: 08/03/2016 12:44PM
Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population






On 03.08.2016 18:38, Brad Cesarone wrote:

Hello All
 
I'm trying to figure out how the webUI populates the user page. I have a mix of 
posix users and non-posix users.
The non-posix users were added using an LDIF and imported fine. I am able to 
view them using ipa user-show, ldapsearch, and if I navigate to them using the 
user details URL they show up. Groups are also able to find the non-posix users 
and verify membership. I am just unable to use ipa user-find or see them in the 
users page.

Hello, I'm afraid you may miss an objectclass in imported users.

Can you please run ipa user-find, and provide SRCH filter from 
/var/log/dirsrv/slapd-*/access  (I hope this is the right path on RHEL6.8)

Then please provide all objectclasses that have a random imported user

regards
Martin

 
I apologize if this has already been answered, I tried google-fu and it didn't 
return anything useful.
Using IPA 3.0 on Redhat 6.8
 
Thanks
-Brad

 -- 
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] IPAv3.0 WebUI User Population

[Martin Basti]

On 03.08.2016 19:58, Brad Cesarone wrote:


Hi Martin
I've been playing with adding objectclasses to the non-posix user. I 
have so far added inetuser, ipaobject, ipasshuser. He started with 
top, person, organizationalPerson, inetOrgPerson and two custom classes.


You need this 'posixaccount' according the source code of IPA 3.3.0

Martin
Nothing came up in /var/log/dirsrv/slapd-*/access when running the 
search but in the /var/log/httpd/error_log there is the 
following entry:  user_find{u'', whoami=False, all=False, 
raw=False, version='2.49', no_members=False, pkey_only=False}: SUCCESS

The command outputted
--
0 users matched
-

Number of Entries Returned 0

Thanks
-Brad

-Martin Basti  wrote: -
To: Brad Cesarone , freeipa-users@redhat.com
From: Martin Basti 
Date: 08/03/2016 12:44PM
Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population



On 03.08.2016 18:38, Brad Cesarone wrote:

Hello All
I'm trying to figure out how the webUI populates the user page. I 
have a mix of posix users and non-posix users.
The non-posix users were added using an LDIF and imported fine. I am 
able to view them using ipa user-show, ldapsearch, and if I navigate 
to them using the user details URL they show up. Groups are also able 
to find the non-posix users and verify membership. I am just unable 
to use ipa user-find or see them in the users page.


Hello, I'm afraid you may miss an objectclass in imported users.

Can you please run ipa user-find, and provide SRCH filter from 
/var/log/dirsrv/slapd-*/access  (I hope this is the right path on RHEL6.8)


Then please provide all objectclasses that have a random imported user

regards
Martin
I apologize if this has already been answered, I tried google-fu and 
it didn't return anything useful.

Using IPA 3.0 on Redhat 6.8
Thanks
-Brad






-- 
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] IPAv3.0 WebUI User Population

[Brad Cesarone]

Hi Martin

I've been playing with adding objectclasses to the non-posix user. I have so 
far added inetuser, ipaobject, ipasshuser. He started with top, person, 
organizationalPerson, inetOrgPerson and two custom classes. 

Nothing came up in /var/log/dirsrv/slapd-*/access when running the search but 
in the /var/log/httpd/error_log there is the following entry:  
user_find{u'', whoami=False, all=False, raw=False, version='2.49', 
no_members=False, pkey_only=False}: SUCCESS

The command outputted 
--
0 users matched
-

Number of Entries Returned 0


Thanks
-Brad

-Martin Basti  wrote: - 
To: Brad Cesarone , freeipa-users@redhat.com
From: Martin Basti 
Date: 08/03/2016 12:44PM
Subject: Re: [Freeipa-users] IPAv3.0 WebUI User Population






On 03.08.2016 18:38, Brad Cesarone wrote:

Hello All
 
I'm trying to figure out how the webUI populates the user page. I have a mix of 
posix users and non-posix users.
The non-posix users were added using an LDIF and imported fine. I am able to 
view them using ipa user-show, ldapsearch, and if I navigate to them using the 
user details URL they show up. Groups are also able to find the non-posix users 
and verify membership. I am just unable to use ipa user-find or see them in the 
users page.

Hello, I'm afraid you may miss an objectclass in imported users.

Can you please run ipa user-find, and provide SRCH filter from 
/var/log/dirsrv/slapd-*/access  (I hope this is the right path on RHEL6.8)

Then please provide all objectclasses that have a random imported user

regards
Martin

 
I apologize if this has already been answered, I tried google-fu and it didn't 
return anything useful.
Using IPA 3.0 on Redhat 6.8
 
Thanks
-Brad

 -- 
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] Declarative configuration options?

[Martin Basti]

On 01.08.2016 22:50, Mike LoSapio wrote:

Hi there,

Is there anyone out there with a good system for storing users,
groups, hosts, etc.. in some sort of version controlled repo w/ flat
files that could plug into "two-man" workflows for user-account
creation and privilege/group membership changes, etc.

There's some github projects out there to help installing FreeIPA
server and a few to get clients up and running, but nothing (that I
could find) for the on-going management of FreeIPA resources.



So in puppet world (just as an example) - I'd be looking for something
like a puppet-defined-type freeipa_user with all the attributes
required and more-importantly all the code-glue that puts it all
together...


Figured I'd ask if there if there's anything already out there before
I re-invent the wheel.


TIA,
--Mike


Hello,

sorry but I don't understand what you exactly need, can you be more 
specific? Do you need a script that provision users?


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] ipa-server-install --external-cert-file and exporting dogtag certificates

[Richard Harmonson]

On Wed, Aug 3, 2016 at 12:49 AM, Florence Blanc-Renaud 
wrote:

> On 08/02/2016 04:52 AM, Richard Harmonson wrote:
>
>> On Mon, Aug 1, 2016 at 10:15 AM, Petr Vobornik > > wrote:
>>
>> On 07/31/2016 07:45 AM, Richard Harmonson wrote:
>> > I having challenges resuming ipa-server-install --external-ca. I
>> am reasonably
>> > confident I am not providing the right certificate and/or format
>> from my
>> > off-line root CA using 389 and Dogtag.
>> >
>> > Does anyone have instructions on how to accomplish the task of
>> exporting the
>> > correct certificates in the expected format?
>> >
>> > Thank you.
>> >
>>
>> The IPA procedure with prerequisites is described at
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca
>>
>> Or are you rather asking for specific PKI instructions?
>>
>> e.g.
>> *
>>
>> http://pki.fedoraproject.org/wiki/PKI_Certificate_CLI#Submitting_a_Certificate_Request
>>
>> *
>>
>> http://pki.fedoraproject.org/wiki/CA_Certificate_Profiles#caCACert:_Manual_Certificate_Manager_Signing_Certificate_Enrollment
>> --
>> Petr Vobornik
>>
>>
>> I read the suggested document, previously, but its an excellent shared
>> reference for this discussion.
>>
>> I have successfully submitted and approved the csr. Dogtag provides a
>> web UI which provides a Base 64 encoded certificate or Base 64 encoded
>> certificate with CA certificate chain in pkcs7 format.
>>
>> For the servercert2010601.pem (the signed CSR request signing CA
>> certificate 0x9) referenced in the article, do I  copy and paste
>> (-BEGIN .. END-) the base 64 (not pkcs7) to a file using *.pem
>> then submit using one of the two --external-cert-file?
>>
>> For the cacert.pem (the Root CA signing certificate 0x1) referenced in
>> the article, do I copy and paste the base 64 with ca in pkcs7 format to
>> a file using *.pkcs7 (or pem or does it matter?) then submit using the
>> second --external-cert-file?
>>
>> Your guidance is much appreciated.
>>
>>
>> Hi Richard,
>
> I tested the following steps to install FreeIPA with a certificate signed
> by an external Dogtag instance:
>
> 1- IPA installation on host ipaserver with:
> ipaserver$ ipa-server-install [options] --external-ca
>
> This step produces the Certificate Signing Request /root/ipa.csr that must
> be provided to the Dogtag server.
>
> 2- On the Dogtag machine, configure Dogtag client authentication (to be
> able to use the command-line):
>
> dogtagsrv$ pki -c password client-init
>
> This step creates a NSSDB in ~/.dogtag/nssdb where the certificates for
> client->dogtag server authentication will be stored.
>
> dogtagsrv$ pk12util -i /root/.dogtag/pki-tomcat/ca_admin_cert.p12 -d
> /root/.dogtag/nssdb/
>
> This step imports the caadmin certificate that was created during Dogtag
> installation into the client NSSDB. The client will be able to authenticate
> as "caadmin" when using Dogtag CLI. Please note the certicate nickname that
> can be found using
>
> dogtagsrv$ certutil -L -d ~/.dogtag/nssdb/
> [...]
> PKI Administrator for  u,u,u
>
> 3- On the Dogtag machine, submit the CSR and approve:
> dogtagsrv$ pki ca-cert-request-submit --profile caCACert --request-type
> pkcs10 --csr-file  /path/to/ipa.csr
>
> This step submits the csr to Dogtag, using the caCACert profile in order
> to produce a Certificate that can be used for a Certificate Authority. Note
> the Request ID in the output as it will be used in the next command to
> approve the CSR and produce the cert:
>
> dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator for
> "  cert-request-review  --action approve
>
> 4- On the Dogtag machine, export the certificate and the dogtag CA cert:
>
> dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator for
> "  cert-show 7 --encoded --output  ipa.cert
> dogtagsrv$ pki ca-cert-show 1 --encoded --output dogtagca.cert
>
> 5- Resume ipa server installation with
>
> ipaserver$ ipa-server-install --external-cert-file=ipa.cert
> --external-cert-file=dogtagca.cert
>
> With those steps, I was able to install FreeIPA server with a 3rd-party
> signed Certificate Authority. Please let me known if you have issues with
> those instructions,
>
> Flo.
>

Awesome!

Flo, your instructions were perfect! I exported the certs and during the
ipa-server-install I see the certs being displayed on the screen then
"Process finished, return code=0, so they are accepted on resuming the
installation. The install fails with a LDAP error but I believe it to be
unrelated to the exported certs. May be a result of my earlier thrashing?

I will recover from a snapshot and begin again. If problems persist, I will
send another request for help for it is probably unrelated to the
certificates.

You got me one step closer. Thank you!

Debug sho

Re: [Freeipa-users] IPAv3.0 WebUI User Population

[Rob Crittenden]

Martin Basti wrote:



On 03.08.2016 18:38, Brad Cesarone wrote:

Hello All
I'm trying to figure out how the webUI populates the user page. I have
a mix of posix users and non-posix users.
The non-posix users were added using an LDIF and imported fine. I am
able to view them using ipa user-show, ldapsearch, and if I navigate
to them using the user details URL they show up. Groups are also able
to find the non-posix users and verify membership. I am just unable to
use ipa user-find or see them in the users page.


Hello, I'm afraid you may miss an objectclass in imported users.

Can you please run ipa user-find, and provide SRCH filter from
/var/log/dirsrv/slapd-*/access (I hope this is the right path on RHEL6.8)

Then please provide all objectclasses that have a random imported user


Martin is right, it is due to missing objectclass(es).

IPA knows what objectclasses constitute and IPA user and user-find (and 
therefore the UI) uses those to find all users (in this case 
posixaccount). So since you have non-POSIX users that's why you don't 
see them.


user-show on the other hand knows where users live and how to build a 
user DN which is why that works.


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] IPAv3.0 WebUI User Population

[Martin Basti]

On 03.08.2016 18:38, Brad Cesarone wrote:

Hello All
I'm trying to figure out how the webUI populates the user page. I have 
a mix of posix users and non-posix users.
The non-posix users were added using an LDIF and imported fine. I am 
able to view them using ipa user-show, ldapsearch, and if I navigate 
to them using the user details URL they show up. Groups are also able 
to find the non-posix users and verify membership. I am just unable to 
use ipa user-find or see them in the users page.


Hello, I'm afraid you may miss an objectclass in imported users.

Can you please run ipa user-find, and provide SRCH filter from 
/var/log/dirsrv/slapd-*/access (I hope this is the right path on RHEL6.8)


Then please provide all objectclasses that have a random imported user

regards
Martin
I apologize if this has already been answered, I tried google-fu and 
it didn't return anything useful.

Using IPA 3.0 on Redhat 6.8
Thanks
-Brad




-- 
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] IPAv3.0 WebUI User Population

[Brad Cesarone]

Hello All

I'm trying to figure out how the webUI populates the user page. I have a mix of 
posix users and non-posix users.
The non-posix users were added using an LDIF and imported fine. I am able to 
view them using ipa user-show, ldapsearch, and if I navigate to them using the 
user details URL they show up. Groups are also able to find the non-posix users 
and verify membership. I am just unable to use ipa user-find or see them in the 
users page.

I apologize if this has already been answered, I tried google-fu and it didn't 
return anything useful.
Using IPA 3.0 on Redhat 6.8

Thanks
-Brad-- 
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] RPM Update fails on some replicas in ipa-server-upgrade

[Patrick Hurrelmann]

On 20.07.2016 17:09, Patrick Hurrelmann wrote:
> Hi all,
>
> today I updated all of our IPA servers (CentOS 7.2) with some minor RPM
> updates, but one of the replicas failed with:
>
> RemoteRetrieveError: Gettext('Failed to authenticate to CA REST API',
> domain='ipa', localedir=None)
>
> Log excerpt (ipaupgrade.log) from this host:
> (Also available as https://paste.fedoraproject.org/392759/90042561/)
>
> 2016-07-20T08:39:10Z INFO [Migrating certificate profiles to LDAP]
> 2016-07-20T08:39:10Z DEBUG Created connection context.ldap2_79620048
> 2016-07-20T08:39:10Z DEBUG flushing
> ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket from SchemaCache
> 2016-07-20T08:39:10Z DEBUG retrieving schema for SchemaCache
> url=ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket
> conn=
> 2016-07-20T08:39:10Z DEBUG Destroyed connection context.ldap2_79620048
> 2016-07-20T08:39:10Z DEBUG request GET
> https://ipa1.loc1.example.com:8443/ca/rest/account/login
> 2016-07-20T08:39:10Z DEBUG request body ''
> 2016-07-20T08:39:10Z DEBUG NSSConnection init ipa1.loc1.example.com
> 2016-07-20T08:39:11Z DEBUG Connecting: 1.2.3.210:0
> 2016-07-20T08:39:11Z DEBUG approved_usage = SSL Server intended_usage =
> SSL Server
> 2016-07-20T08:39:11Z DEBUG cert valid True for
> "CN=ipa1.loc1.example.com,O=Example Org,OU=CA,L=City,ST=State,C=DE"
> 2016-07-20T08:39:11Z DEBUG handshake complete, peer = 1.2.3.210:8443
> 2016-07-20T08:39:11Z DEBUG Protocol: TLS1.2
> 2016-07-20T08:39:11Z DEBUG Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> 2016-07-20T08:39:11Z DEBUG response status 401
> 2016-07-20T08:39:11Z DEBUG response headers {'content-length': '951',
> 'content-language': 'en', 'expires': 'Thu, 01 Jan 1970 01:00:00 CET',
> 'server': 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed,
> 20 Jul 2016 08:39:11 GMT', 'content-type': 'text/html;charset=utf-8',
> 'www-authenticate': 'Basic realm="Certificate Authority"'}
> 2016-07-20T08:39:11Z DEBUG response body 'Apache
> Tomcat/7.0.54 - Error report
> HTTP Status 401 -  noshade="noshade">type Status reportmessage
> description This request requires HTTP
> authentication.Apache
> Tomcat/7.0.54'
> 2016-07-20T08:39:11Z ERROR IPA server upgrade failed: Inspect
> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
> 2016-07-20T08:39:11Z DEBUG   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> execute
> return_value = self.run()
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
> line 48, in run
> server.upgrade()
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> line 1618, in upgrade
> upgrade_configuration()
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> line 1548, in upgrade_configuration
> ca_enable_ldap_profile_subsystem(ca)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> line 341, in ca_enable_ldap_profile_subsystem
> cainstance.migrate_profiles_to_ldap(caconfig)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
> 1868, in migrate_profiles_to_ldap
> _create_dogtag_profile(profile_id, profile_data, overwrite=False)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
> 1874, in _create_dogtag_profile
> with api.Backend.ra_certprofile as profile_api:
>   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py",
> line 2038, in __enter__
> raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to
> CA REST API'))
>
> 2016-07-20T08:39:11Z DEBUG The ipa-server-upgrade command failed,
> exception: RemoteRetrieveError: Gettext('Failed to authenticate to CA
> REST API', domain='ipa', localedir=None)
> 2016-07-20T08:39:11Z ERROR Unexpected error - see
> /var/log/ipaupgrade.log for details:
> RemoteRetrieveError: Gettext('Failed to authenticate to CA REST API',
> domain='ipa', localedir=None)
>
>
> And with further help from mbaste on IRC, I found the following error in
> ca debug log:
> (Also available as https://paste.fedoraproject.org/392897/02195914/)
>
> [20/Jul/2016:10:39:04][profileChangeMonitor]: BasicProfile: done init
> [20/Jul/2016:10:39:04][profileChangeMonitor]: Done Profile Creation -
> IECUserRoles
> [20/Jul/2016:10:39:11][http-bio-8443-exec-4]: PKIRealm.logDebug:
> Authe

Re: [Freeipa-users] How to delete a managed group

[Rob Crittenden]

Bob Hinton wrote:

On 03/08/2016 07:15, Petr Spacek wrote:

On 3.8.2016 00:58, Bob Hinton wrote:

Hi,

Something went wrong when trying to restore some preserved users so I
deleted them and then tried to recreate them. This failed with -

ipa: ERROR: Unable to create private group. A group 'X'  already exists.

Trying to delete this group produces -

ipa: ERROR: Unable to create private group. A group 'X' already exists.

Trying to detach it with

ipa group-detach X

produces

ipa: ERROR: X: group not found

ipa group-show X

I would try
$ ipa group show X --all --raw

that could show us if there is something interesting like replication conflict
or so.

Petr^2 Spacek

Hi Petr,

This produces ...

ipa group-show X --all --raw
   dn: cn=X,cn=groups,cn=accounts,dc=local,dc=com
   cn: X
   description: User private group for X
   gidnumber: 799830053
   ipaUniqueID: 3b8e0ec8-58c4-11e6-806d-005056015864
   mepManagedBy: uid=X,cn=users,cn=accounts,dc=local,dc=com
   objectClass: posixgroup
   objectClass: ipaobject
   objectClass: mepManagedEntry
   objectClass: top

We do have some replication problems at the moment - two recreated
replicas currently have two RUVs so this could this be how the user
delete completed without the corresponding group?


Not sure. The 389-ds plugin should, by definition, remove the group when 
a user is deleted. I'd be more inclined to believe that the group was 
added and the user not in a replication event.


Removing the group requires an ldapmodify:

% kinit admin
% ldapmodify -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: ad...@example.com
SASL SSF: 56
SASL data security layer installed.
dn: cn=deleteme,cn=groups,cn=accounts,dc=example,dc=com
changetype: modify
delete: objectclass
objectclass: mepManagedEntry
-
delete: mepManagedBy
mepManagedBy: uid=deleteme,cn=users,cn=accounts,dc=example,dc=com
^D
modifying entry "cn=deleteme,cn=groups,cn=accounts,dc=example,dc=com"

% ipa group-del deleteme

Deleted group "deleteme"


Makes me wonder if the managed entry plugin should allow deletion if the 
other side of the link doesn't exist. I'll investigate this.


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] ipa-server-install --external-cert-file and exporting dogtag certificates

[Florence Blanc-Renaud]

On 08/02/2016 04:52 AM, Richard Harmonson wrote:

On Mon, Aug 1, 2016 at 10:15 AM, Petr Vobornik mailto:pvobo...@redhat.com>> wrote:

On 07/31/2016 07:45 AM, Richard Harmonson wrote:
> I having challenges resuming ipa-server-install --external-ca. I
am reasonably
> confident I am not providing the right certificate and/or format
from my
> off-line root CA using 389 and Dogtag.
>
> Does anyone have instructions on how to accomplish the task of
exporting the
> correct certificates in the expected format?
>
> Thank you.
>

The IPA procedure with prerequisites is described at

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca

Or are you rather asking for specific PKI instructions?

e.g.
*

http://pki.fedoraproject.org/wiki/PKI_Certificate_CLI#Submitting_a_Certificate_Request

*

http://pki.fedoraproject.org/wiki/CA_Certificate_Profiles#caCACert:_Manual_Certificate_Manager_Signing_Certificate_Enrollment
--
Petr Vobornik


I read the suggested document, previously, but its an excellent shared
reference for this discussion.

I have successfully submitted and approved the csr. Dogtag provides a
web UI which provides a Base 64 encoded certificate or Base 64 encoded
certificate with CA certificate chain in pkcs7 format.

For the servercert2010601.pem (the signed CSR request signing CA
certificate 0x9) referenced in the article, do I  copy and paste
(-BEGIN .. END-) the base 64 (not pkcs7) to a file using *.pem
then submit using one of the two --external-cert-file?

For the cacert.pem (the Root CA signing certificate 0x1) referenced in
the article, do I copy and paste the base 64 with ca in pkcs7 format to
a file using *.pkcs7 (or pem or does it matter?) then submit using the
second --external-cert-file?

Your guidance is much appreciated.



Hi Richard,

I tested the following steps to install FreeIPA with a certificate 
signed by an external Dogtag instance:


1- IPA installation on host ipaserver with:
ipaserver$ ipa-server-install [options] --external-ca

This step produces the Certificate Signing Request /root/ipa.csr that 
must be provided to the Dogtag server.


2- On the Dogtag machine, configure Dogtag client authentication (to be 
able to use the command-line):


dogtagsrv$ pki -c password client-init

This step creates a NSSDB in ~/.dogtag/nssdb where the certificates for 
client->dogtag server authentication will be stored.


dogtagsrv$ pk12util -i /root/.dogtag/pki-tomcat/ca_admin_cert.p12 -d 
/root/.dogtag/nssdb/


This step imports the caadmin certificate that was created during Dogtag 
installation into the client NSSDB. The client will be able to 
authenticate as "caadmin" when using Dogtag CLI. Please note the 
certicate nickname that can be found using


dogtagsrv$ certutil -L -d ~/.dogtag/nssdb/
[...]
PKI Administrator for  u,u,u

3- On the Dogtag machine, submit the CSR and approve:
dogtagsrv$ pki ca-cert-request-submit --profile caCACert --request-type 
pkcs10 --csr-file  /path/to/ipa.csr


This step submits the csr to Dogtag, using the caCACert profile in order 
to produce a Certificate that can be used for a Certificate Authority. 
Note the Request ID in the output as it will be used in the next command 
to approve the CSR and produce the cert:


dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator for 
"  cert-request-review  --action approve


4- On the Dogtag machine, export the certificate and the dogtag CA cert:

dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator for 
"  cert-show 7 --encoded --output  ipa.cert

dogtagsrv$ pki ca-cert-show 1 --encoded --output dogtagca.cert

5- Resume ipa server installation with

ipaserver$ ipa-server-install --external-cert-file=ipa.cert 
--external-cert-file=dogtagca.cert


With those steps, I was able to install FreeIPA server with a 3rd-party 
signed Certificate Authority. Please let me known if you have issues 
with those instructions,


Flo.

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