Re: [Freeipa-users] Should IPA Replica DNS SOA Serials match?

[Baird, Josh]

Yes, this is expected.

>From the IPA documentation [1]:

"The IdM-integrated DNS is multi-master. SOA serial numbers in IdM zones are 
not synchronized between IdM servers. For this reason, configure DNS slave 
servers to only use one IdM master server. This prevents zone transfer failures 
caused by non-synchronized SOA serial numbers."

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#zone-transfers

Thanks,

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jake
Sent: Friday, January 6, 2017 2:25 PM
To: freeipa-users 
Subject: [Freeipa-users] Should IPA Replica DNS SOA Serials match?

Hey All,
I currently have 4 ipa 4.2 masters and none of the SOA Serials match, is this 
expected behavior of bind-ldap?

ipa01 - 1483710336
ipa02 - 1483709696
ipa03 - 1483730432
ipa04 - 1483714048

Thanks!

-Jake

-- 
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 4.4 replica installation failing

[Baird, Josh]

Martin,

Yes, this is the exact scenario.  My lab started with a RHEL 7.2 master/replica 
with 'domain level' set to 0.  

I raised the 'domain level' to 1, and now I'm trying to introduce a new replica 
into the environment.

I will check on 'nsds5replicabinddn' and report back.

Thanks,

Josh

-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com] 
Sent: Friday, November 18, 2016 3:17 AM
To: Baird, Josh <jba...@follett.com>; 'freeipa-users@redhat.com' 
<freeipa-users@redhat.com>
Subject: Re: [Freeipa-users] IPA 4.4 replica installation failing

On 11/17/2016 03:51 PM, Baird, Josh wrote:
> Hi all,
>
> In my IPA 4.4 lab (RHEL 7.3), I'm trying to install/configure a new replica, 
> and I seem to be hitting something similar to #5412 [1].
>
> The 'ipa-replica-install' is getting stuck on:
>
>   [4/26]: creating installation admin user
>
> Dirsrv error logs on the new replica:
>
> [17/Nov/2016:08:45:09.342813042 -0600] NSMMReplicationPlugin - 
> agmt="cn=caToimqa-d1-dc01.qa-unix.domain.com" (imqa-d1-dc01:389): Unable to 
> acquire replica: permission denied. The bind dn "" does not have permission 
> to supply replication updates to the replica. Will retry later.
>
> Dirsrv access logs on existing master:
>
> [17/Nov/2016:08:39:59.244698389 -0600] conn=121 op=83 RESULT err=0 
> tag=101 nentries=0 etime=0
> [17/Nov/2016:08:40:00.248620354 -0600] conn=121 op=84 SRCH 
> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" 
> scope=0 filter="(objectClass=*)" attrs=ALL
> [17/Nov/2016:08:40:00.248917257 -0600] conn=121 op=84 RESULT err=0 
> tag=101 nentries=0 etime=0
> [17/Nov/2016:08:40:01.253067200 -0600] conn=121 op=85 SRCH 
> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" 
> scope=0 filter="(objectClass=*)" attrs=ALL
> [17/Nov/2016:08:40:01.253481728 -0600] conn=121 op=85 RESULT err=0 
> tag=101 nentries=0 etime=0
> [17/Nov/2016:08:40:02.257477560 -0600] conn=121 op=86 SRCH 
> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" 
> scope=0 filter="(objectClass=*)" attrs=ALL
> [17/Nov/2016:08:40:02.257813691 -0600] conn=121 op=86 RESULT err=0 
> tag=101 nentries=0 etime=0
> [17/Nov/2016:08:40:03.261805482 -0600] conn=121 op=88 SRCH 
> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" 
> scope=0 filter="(objectClass=*)" attrs=ALL
> [17/Nov/2016:08:40:03.262310788 -0600] conn=121 op=88 RESULT err=0 
> tag=101 nentries=0 etime=0
>
> Dirsrv logs on the existing master:
>
> [17/Nov/2016:08:40:20.644554573 -0600] NSMMReplicationPlugin - 
> conn=120 op=13 replica="o=ipaca": Unable to acquire replica: error: 
> permission denied
> [17/Nov/2016:08:41:57.858672215 -0600] NSMMReplicationPlugin - 
> conn=123 op=5 replica="o=ipaca": Unable to acquire replica: error: 
> permission denied
> [17/Nov/2016:08:45:09.334188374 -0600] NSMMReplicationPlugin - 
> conn=130 op=5 replica="o=ipaca": Unable to acquire replica: error: 
> permission denied
>
> Has anyone else experienced this issue?
>
> Thanks,
>
> Josh
>
> [1] https://fedorahosted.org/freeipa/ticket/5412
>
>
Hi Josh,

in the original ticket the issue was occuring when creating CA replica against 
7.2 master upgraded to 7.3 with domain level raised to 1. Do you have the same 
scenario?

Also, during the stuck installation can you check for the presence of replica's 
LDAP principal in 'nsds5replicabinddn' attribute on master's 
'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry?

I would also check for the reverse, i.e. if the master's LDAP principal is in 
the 'nsds5replicabinddn' attribute on replica's 
'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry.

--
Martin^3 Babinsky

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

[Freeipa-users] IPA 4.4 replica installation failing

[Baird, Josh]

Hi all,

In my IPA 4.4 lab (RHEL 7.3), I'm trying to install/configure a new replica, 
and I seem to be hitting something similar to #5412 [1].

The 'ipa-replica-install' is getting stuck on:

  [4/26]: creating installation admin user

Dirsrv error logs on the new replica:

[17/Nov/2016:08:45:09.342813042 -0600] NSMMReplicationPlugin - 
agmt="cn=caToimqa-d1-dc01.qa-unix.domain.com" (imqa-d1-dc01:389): Unable to 
acquire replica: permission denied. The bind dn "" does not have permission to 
supply replication updates to the replica. Will retry later.

Dirsrv access logs on existing master:

[17/Nov/2016:08:39:59.244698389 -0600] conn=121 op=83 RESULT err=0 tag=101 
nentries=0 etime=0
[17/Nov/2016:08:40:00.248620354 -0600] conn=121 op=84 SRCH 
base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 
filter="(objectClass=*)" attrs=ALL
[17/Nov/2016:08:40:00.248917257 -0600] conn=121 op=84 RESULT err=0 tag=101 
nentries=0 etime=0
[17/Nov/2016:08:40:01.253067200 -0600] conn=121 op=85 SRCH 
base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 
filter="(objectClass=*)" attrs=ALL
[17/Nov/2016:08:40:01.253481728 -0600] conn=121 op=85 RESULT err=0 tag=101 
nentries=0 etime=0
[17/Nov/2016:08:40:02.257477560 -0600] conn=121 op=86 SRCH 
base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 
filter="(objectClass=*)" attrs=ALL
[17/Nov/2016:08:40:02.257813691 -0600] conn=121 op=86 RESULT err=0 tag=101 
nentries=0 etime=0
[17/Nov/2016:08:40:03.261805482 -0600] conn=121 op=88 SRCH 
base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 
filter="(objectClass=*)" attrs=ALL
[17/Nov/2016:08:40:03.262310788 -0600] conn=121 op=88 RESULT err=0 tag=101 
nentries=0 etime=0

Dirsrv logs on the existing master:

[17/Nov/2016:08:40:20.644554573 -0600] NSMMReplicationPlugin - conn=120 op=13 
replica="o=ipaca": Unable to acquire replica: error: permission denied
[17/Nov/2016:08:41:57.858672215 -0600] NSMMReplicationPlugin - conn=123 op=5 
replica="o=ipaca": Unable to acquire replica: error: permission denied
[17/Nov/2016:08:45:09.334188374 -0600] NSMMReplicationPlugin - conn=130 op=5 
replica="o=ipaca": Unable to acquire replica: error: permission denied

Has anyone else experienced this issue?

Thanks,

Josh

[1] https://fedorahosted.org/freeipa/ticket/5412


-- 
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] IPA 4.4 and Trust Agents/Controllers

[Baird, Josh]

Hi,

I'm currently testing an IPA 4.3 (RHEL 7.2) to IPA 4.4 (RHEL 7.3) upgrade and 
had a few questions about the concept of trust agents/controllers.

Prior to IPA 4.4, were all IPA masters (that 'ipa-adtrust-install' was ran on)  
considered 'trust controllers'?  In my lab, the upgrade automatically 
provisioned my IPA masters as controllers (not agents).  Is this the default 
behavior? 

The official recommendation appears to be to minimize the number of trust 
controllers.  Given an IPA deployment with two masters in each location, is the 
recommendation to only have 1 of these configured as a 'trust controller' and 
the other as a 'trust agent'?

What happens if all 'trust controllers' become unavailable, but 'trust agents' 
remain available?  Will the trust between IPA and AD be broken?

Thanks,

Josh




-- 
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] Novice question re IPA management of host RBAC login, sudo and ssh key management for users who are only in Active Directory

[Baird, Josh]

Hi,

If I'm understanding you correctly - you will want to nest 'external' groups 
into POSIX groups for assigning policy (HBAC, sudo, etc) to your AD users.  
There are examples of this in the IdM documentation, but the gist is:

* Create an 'external' group in IPA (eg, ipa-group-add external_admins 
--external)
* Add your AD group as a member to the external group (eg, ipa group-add-member 
external_admins --external 'AD\groupname)
* Create a standard POSIX group in IPA (eg, ipa group-add admins)
* Add the external group as a member to the POSIX group (eg, 
ipa-group-add-members admins --groups external_admins)

Now you can define policy (HBAC, sudo) based on the 'admins' POSIX group and 
the policies will apply to the AD users in the AD\groupname group.

Hope this helps.

Thanks,

Josh

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Chris Dagdigian
Sent: Wednesday, October 19, 2016 3:18 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Novice question re IPA management of host RBAC login, 
sudo and ssh key management for users who are only in Active Directory

Thanks to great tips and pointers from people on this list (h/t Alexander B) I 
was able to build an IPA master + replica setup that can recognize and allow 
logins from users coming from multiple disconnected AD Forests with 1-way 
trusts to the IPA servers

Sanitized view of our AWS footprint:

AD Servers & IPA:

AD Forest #1:   company-test.org
AD Forest #2:   company-aws.org
AD Forest #3:   company.org
IPA Domain/Realm:company-ipa.org   (successful 1-way trusts to 
company-test.org and company-aws.org etc.)

With basic recognition of users and working SSH logins based on AD username and 
passwords I'm moving on to trying to use the far more interesting IPA/IDM 
features.

Using user accounts defined locally on the IPA server I'm having a blast 
uploading SSH keys and creating sudo rules and groups. So the natural next 
question is "can we do this for users who exist only in remote AD controllers?

IPA is doing 100% of the UID/GID/Posix stuff management - we are only pulling 
usernames & groups from AD and checking passwords against the AD servers.

The basic question -- is it possible for me to get to "hybrid linux user 
management" nirvana whereby IPA/IDM manages everything about AD users except 
for their username and passwords?

Tried to find this in the official documentation but it dives instantly into 
deep topics about user data mapping, custom schemas and dealing with POSIX data 
served up by the AD controllers. Hard to figure out the boundary between what 
IPA can support with local user accounts vs  what it can do when the users 
exist in remote AD forests.

Any URLs or documentation pointers would be appreciated

Regards,
Chris




--
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] Naming conventions/practices for HBAC/sudo/etc

[Baird, Josh]

Hi all,

I realize that this with vary from instance to instance, but I'm curious on how 
others are handling naming conventions for things like HBAC rules, sudo rules, 
etc.

Here is how I am handling things today:

* External groups have an 'external' prefix (eg, external_groupname)
* Hostgroups have a $group prefix (eg, groupX_webservers)
* sudo rules are classified by the group name (eg, EmailAdmins)

This example sudo rule would allow members of the 'EmailAdmins' group access to 
run certain commands/command-groups on specific host-groups (eg, 
groupX_webservers).

* HBAC rules are classified by the group name (eg, allow_EmailAdmins)

This example HBAC rule would allow members of the 'EmailAdmins' group access to 
certain host-groups (eg, groupX_webservers).  When this group needs to access 
additional groups of servers, I just modify the existing HBAC rule and add the 
new group.  There are many different ways to handle this.  I have thought about 
classifying HBAC rules by hostgroup instead of user group.  In this case, I 
would have an HBAC rule named 'allow_Webservers' where I would specify 
individual user-groups that require access to the host(s).  My opinion on this 
is likely to change as our environment (and use cases) continues to expand.

What is working in your environment?  What would you change if you could start 
over?  It would be great if this discussion could eventually lead to a 'best 
practices' document/wiki-page for naming conventions and practices.

Thanks,

Josh



-- 
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] Problems with web console in IPA

[Baird, Josh]

Hi,

We are running the most recent IPA packages in RHEL7 and are facing a few 
issues when accessing the web console:

First, since we utilize a Kerberos trust with AD, we had to create 'internal' 
IPA users that we use to login to the web console.  I believe it is expected 
that AD users cannot login to the web console, but this may be coming in a 
future version?

Secondly, when we browse to the web console from a Windows system that is 
joined to our AD domain, we first see a 'basic auth' popup that asks us for our 
user credentials.  No username or password is accepted here.  If we hit 
'Escape' the normal IPA forms-based authentication appears.  We are able to 
login via this form.  What is causing the 'basic auth' popup?

Lastly, we are not able to login *unless* we use Chrome's 'incognito mode.'  If 
we browse to the web console in a normal browser, we first have to escape out 
of the 'basic-auth' window, but after we input our username/password into the 
form, another 'basic-auth' window pops up.  If we escape out of this, the forms 
based login now displays 'Your session has expired.  Please re-login.'  Because 
of this, we *have* to use Chrome's incognito function.

Can anyone offer some suggestions or advice for these problems?

Thanks,

Josh


-- 
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 users home directory automount

[Baird, Josh]

I would start by reading the documentation [1].

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/automount.html

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ben .T.George
Sent: Wednesday, May 18, 2016 10:04 AM
To: Michael ORourke 
Cc: freeipa-users 
Subject: Re: [Freeipa-users] AD users home directory automount

HI,

Thanks for the reply.

actually i don't want to share from my Trusted AD. My san has cifs and NFS 
capability.

in this case how can i proceed? usually while installing client, i used to give 
below options

ipa-client-install --server global.ipa.local  --domain ipa.local --mkhomedir 
--fixed-primary

so whenever user loggedin, it creates home directory automatically under 
/home/DOMAIN/user.

regards,
Ben

On Wed, May 18, 2016 at 4:00 PM, Michael ORourke 
> wrote:
Yes, because you can point the automount maps to whatever device you want.  
NFSv4 might be more tricky to setup on a SAN device and may or may not work 
depending on the software/firmware of the device.  NFSv3 is a well supported 
protocol across SAN vendors and you should not have any problems setting that 
up.  I've used Openfiler on a white-box SAN with home dirs and automount maps 
which is working fine for us.
I wonder if you could do some sort of CIFS home dir automount with a SAN that 
is joined to an AD domain which is trusted by FreeIPA?  Seems like this would 
be feasible.

-Mike
-Original Message-
From: "Ben .T.George"
Sent: May 18, 2016 7:38 AM
To: freeipa-users
Subject: [Freeipa-users] AD users home directory automount
HI LIst,

Is it possible to mount home directories of AD authenticated users from 
external source(like san or fileshare)

Regards,
Ben

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

-- 
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] Samba Integration with AD Trust

[Baird, Josh]

Actually - it looks like this is working.  I think I had something cached on 
the Windows client that I was testing from.

Thanks for the help.

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Baird, Josh
> Sent: Wednesday, March 23, 2016 9:11 AM
> To: 'freeipa-users@redhat.com'
> Subject: Re: [Freeipa-users] Samba Integration with AD Trust
> 
> Justin,
> 
> @ad_admins is an AD group, correct (not a POSIX group), correct?  I still
> cannot get this working.  Home directory shares are working fine.
> 
> (apologies for the broken threading - I don't think I received your message
> for some reason)
> 
> Thanks,
> 
> Josh
> 
> > -----Original Message-
> From: Justin Stephenson 
> To: "Baird, Josh" ,   "'freeipa-users redhat com'"
> 
> Subject: Re: [Freeipa-users] Samba Integration with AD Trust
> Date: Tue, 22 Mar 2016 15:09:50 -0400
> I have used the following successfully in the past:
> 
> [shared]
> path = /home/shared
> valid users = @ad_admins
> read only = No
> guest ok = Yes
> 
> This requires the sssd-libwbclient rpm which may be installed already as a
> dependency.
> 
> -Justin
> 
> > -Original Message-
> > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> > boun...@redhat.com] On Behalf Of Baird, Josh
> > Sent: Tuesday, March 22, 2016 2:50 PM
> > To: 'freeipa-users@redhat.com'
> > Subject: [Freeipa-users] Samba Integration with AD Trust
> >
> > Hi all,
> >
> > I'm attempting to integrate Samba 4.2.3 with IPA 4.2 (RHEL7).  I have
> > a kerberos trust established between IPA and AD.  I have followed the
> > instructions on the wiki [1], but had some questions and problems
> > specifically related to share permissions:
> >
> > I'm having trouble with shares where I need to grant access to a
> > specific AD user/group.  I have tried this and other variations with no
> success:
> >
> > [shared]
> > path = /home/shared
> > writable = yes
> > browsable = yes
> > valid users = testsa...@ad.domain.lan
> >
> > I have also tried:
> >
> > valid users = ad\testsamba
> > vaild users= @ad\testsamba
> > valid users= @testsa...@ad.domain.lan
> >
> >
> > What is the proper way to allow specific AD groups access to the Samba
> > share?  I also tried nesting an external group in a POSIX group with
> > no success.  Should I be using something other than 'valid users'?
> >
> >  [1]
> >
> http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_Wi
> > th_IPA
> >
> > Thanks,
> >
> > Josh
> >
> > --
> > 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

-- 
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] Samba Integration with AD Trust

[Baird, Josh]

Justin,

@ad_admins is an AD group, correct (not a POSIX group), correct?  I still 
cannot get this working.  Home directory shares are working fine.

(apologies for the broken threading - I don't think I received your message for 
some reason)

Thanks,

Josh

> -Original Message-
From: Justin Stephenson 
To: "Baird, Josh" , "'freeipa-users redhat com'" 

Subject: Re: [Freeipa-users] Samba Integration with AD Trust
Date: Tue, 22 Mar 2016 15:09:50 -0400
I have used the following successfully in the past:

[shared]
path = /home/shared
valid users = @ad_admins
read only = No
guest ok = Yes

This requires the sssd-libwbclient rpm which may be installed already as a 
dependency.

-Justin

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Baird, Josh
> Sent: Tuesday, March 22, 2016 2:50 PM
> To: 'freeipa-users@redhat.com'
> Subject: [Freeipa-users] Samba Integration with AD Trust
> 
> Hi all,
> 
> I'm attempting to integrate Samba 4.2.3 with IPA 4.2 (RHEL7).  I have a
> kerberos trust established between IPA and AD.  I have followed the
> instructions on the wiki [1], but had some questions and problems specifically
> related to share permissions:
> 
> I'm having trouble with shares where I need to grant access to a specific AD
> user/group.  I have tried this and other variations with no success:
> 
> [shared]
>   path = /home/shared
>   writable = yes
>   browsable = yes
>   valid users = testsa...@ad.domain.lan
> 
> I have also tried:
> 
>   valid users = ad\testsamba
>   vaild users= @ad\testsamba
>   valid users= @testsa...@ad.domain.lan
> 
> 
> What is the proper way to allow specific AD groups access to the Samba
> share?  I also tried nesting an external group in a POSIX group with no
> success.  Should I be using something other than 'valid users'?
> 
>  [1]
> http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_Wi
> th_IPA
> 
> Thanks,
> 
> Josh
> 
> --
> 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] Samba Integration with AD Trust

[Baird, Josh]

Hi all,

I'm attempting to integrate Samba 4.2.3 with IPA 4.2 (RHEL7).  I have a 
kerberos trust established between IPA and AD.  I have followed the 
instructions on the wiki [1], but had some questions and problems specifically 
related to share permissions:

I'm having trouble with shares where I need to grant access to a specific AD 
user/group.  I have tried this and other variations with no success:

[shared]
path = /home/shared
writable = yes
browsable = yes
valid users = testsa...@ad.domain.lan

I have also tried:

valid users = ad\testsamba
vaild users= @ad\testsamba
valid users= @testsa...@ad.domain.lan


What is the proper way to allow specific AD groups access to the Samba share?  
I also tried nesting an external group in a POSIX group with no success.  
Should I be using something other than 'valid users'?

 [1] http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA

Thanks,

Josh

-- 
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 / AD Trust Relationship

[Baird, Josh]

No, logging into Windows AD clients using IPA credentials is not currently 
supported.  This functionality is currently under development.

See this thread [1] for more information.

[1] https://www.redhat.com/archives/freeipa-users/2016-February/msg00119.html

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Josh Pospisil
Sent: Wednesday, February 03, 2016 12:18 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] FreeIPA / AD Trust Relationship

I have successfully set up a trust between AD (windows server 2012) and freeIPA 
following this guide: http://www.freeipa.org/page/Active_Directory_trust_setup

My hope in doing this was to allow the users I have created on the freeIPA 
server to logon to our windows computers without recreating all of the users in 
AD, but this is not working.  Can anyone verify whether or not this should be 
true or does the trust only work the opposite direction?  If it should be true, 
can anyone offer any tips for troubleshooting?

When I try to verify the trust on the AD server, I get the following error: 
"There are currently no logon servers available to service the logon request."

Dns was setup as described in the guide above.

Thanks in advance for any help.


Josh
-- 
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-AD Login

[Baird, Josh]

It sounds like you are trying to login to Windows AD clients using IPA 
credentials?

If so, I do not believe this functionality is currently supported.

Thanks,

Josh

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Sunday, February 07, 2016 8:13 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA-AD Login
> 
> On Fri, Feb 05, 2016 at 06:21:56PM -0600, Alan P wrote:
> > Thanks jhrozek, I have already seen it and applied to my IPA server, but it
> didn't have any significant impact, at least for AD users. In krb5kdc log, 
> when
> I try to login with an IPA user in Windows, I can see the next:
> >
> > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ
> > (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: NEEDED_PREAUTH:
> > ipa.u...@ipa.ad.example.com for
> > krbtgt/ipa.ad.example@ipa.ad.example.com, Additional
> > pre-authentication required Feb 05 17:52:12 master.ipa.ad.example.com
> > krb5kdc[14081](info): closing down fd 12 Feb 05 17:52:12
> > master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18
> > 17 23 24 -135 3}) 172.19.21.37: ISSUE: authtime 1454716332, etypes
> > {rep=18 tkt=18 ses=18}, ipa.u...@ipa.ad.example.com for
> > krbtgt/ipa.ad.example@ipa.ad.example.com
> > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info):
> > closing down fd 12 Feb 05 17:52:12 master.ipa.ad.example.com
> > krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135})
> > 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18
> > ses=18}, ipa.u...@ipa.ad.example.com for
> > krbtgt/ad.example@ipa.ad.example.com
> > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info):
> > closing down fd 12 Feb 05 17:58:45 master.ipa.ad.example.com
> > krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135})
> > 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18
> > ses=18}, ipa.u...@ipa.ad.example.com for
> > cifs/master.ipa.ad.example@ipa.ad.example.com
> > Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info):
> > closing down fd 12 Feb 05 17:58:47 master.ipa.ad.example.com
> > krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135})
> > 172.19.21.37: LOOKING_UP_SERVER: authtime 0,
> > ipa.u...@ipa.ad.example.com for
> > ProtectedStorage/master.ipa.ad.example@ipa.ad.example.com,
> Server
> > not found in Kerberos database Feb 05 17:58:47
> > master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12
> >
> >
> > In Windows, I can't find something related.
> >
> > Any other suggestion?
> 
> Which part of the login is slow? Acquiring ticket with kinit or establishing
> the user groups etc? Usually it's the latter, so looking at sssd logs and
> checking what takes so long is the best way forward in most cases. You can
> also confirm if the group resolution takes a long time with:
> sss_cache -E; id $aduser@addomain
> 
> --
> 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-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User)

[Baird, Josh]

For AD users, I believe you have two options.

1) Set the POSIX value on the user in AD for the shell
2) Set the following in your client's sssd.conf:

[nss]
override_shell = /bin/bash

This would obviously be global per IPA client.

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jon
Sent: Thursday, February 04, 2016 2:25 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD 
users (e.g. how do I set a shell for an AD User)

Hello,

How does one manage linux attributes for AD users.  Primarily in my case, I'm 
looking to change the default shell to either Bash or KSH depending on the user.

I can create a .profile that either sources bash or ksh rcs... e.g.:

>> $ cat ~/.profile
>> bash ./.bashrc

This is really less than ideal and just seems like the wrong way to do it, 
especially considering we have a tool like FreeIPA.

According to 
Microsoft,
 they are no longer supporting Identity Management for Unix.  Does FreeIPA 
honor the attributes set by IDMU?  Even if it's deprecated, I suppose we could 
continue to use it...
This previous FreeIPA 
thread 
seems to indicate you can force the shell for anyone in the domain logging into 
that machine, but we have some users who prefer one shell over the other.

I did what I believe to be standard, I created a security group in AD, added 
that group to a group an external group in FreeIPA, then made an internal group 
and added the external group as a member to the internal group.  Unfortunately, 
this doesn't seem to expose any of the AD attributes for management.  Or maybe 
I'm just misunderstanding...

Any thoughts?  How are you managing individual AD user settings?

Thanks,
Jon A

-- 
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] what is the sudo rule runasuser local user account

[Baird, Josh]

Actually, I use local (external) users in my sudo rules in IPA 4.2 with no 
problem.

Example:

  Rule name: TestDBAs
  Description: access for members of the TestDBAs group
  Enabled: TRUE
  Command category: all
  User Groups: testdbas
  Host Groups: corp_oracle
  RunAs External User: oracle

In this example, 'oracle' is a local user on the server (not in IPA).  I hope 
this functionality does not go away.

Thanks,

Josh

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Rob Verduijn
> Sent: Thursday, February 04, 2016 10:54 AM
> To: Jakub Hrozek
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user
> account
> 
> On Centos7.2 all patches applied I used the command:
> ipa-client-install --enable-dns-updates
> 
> Rob
> 
> 2016-02-04 16:45 GMT+01:00 Jakub Hrozek :
> > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote:
> >> Hello,
> >>
> >> I've noticed that the sudorule-add-runasuser no longer has en
> >> --external option
> >>
> >> What is the current method to add a local service account to a sud
> >> rule list so that users may run sudo as that service account (ie
> >> apache or jboss)
> >>
> >> Cheers
> >> Rob Verudijn
> >
> > I know I'm not answering your question but how did you configure the
> > client side earlier? Did you use the native/legacy sudo ldap driver?
> >
> > The reason I'm asking this is that sssd only supports users it
> > handles, so in the IPA case it only supports IPA users anyway..
> >
> > --
> > 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

-- 
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] what is the sudo rule runasuser local user account

[Baird, Josh]

Yeah, this seems strange:

  --externaluser=STRExternal User the rule applies to (sudorule-find only)
  --runasexternaluser=STR
External User the commands can run as (sudorule-find
only)
  --runasexternalgroup=STR
External Group the commands can run as (sudorule-find
only)

I'm not sure why those commands would be limited to sudorule-find only.

Josh

> -Original Message-
> From: Rob Verduijn [mailto:rob.verdu...@gmail.com]
> Sent: Thursday, February 04, 2016 11:13 AM
> To: Baird, Josh
> Cc: Jakub Hrozek; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user
> account
> 
> That does seem to work for me as well,
> however I can only add the external user via the web-gui
> 
> Any idea how to do this with the command line tools ?
> 
> Rob Verduijn
> 
> 2016-02-04 17:00 GMT+01:00 Baird, Josh <jba...@follett.com>:
> > Actually, I use local (external) users in my sudo rules in IPA 4.2 with no
> problem.
> >
> > Example:
> >
> >   Rule name: TestDBAs
> >   Description: access for members of the TestDBAs group
> >   Enabled: TRUE
> >   Command category: all
> >   User Groups: testdbas
> >   Host Groups: corp_oracle
> >   RunAs External User: oracle
> >
> > In this example, 'oracle' is a local user on the server (not in IPA).  I 
> > hope this
> functionality does not go away.
> >
> > Thanks,
> >
> > Josh
> >
> >> -Original Message-
> >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> >> boun...@redhat.com] On Behalf Of Rob Verduijn
> >> Sent: Thursday, February 04, 2016 10:54 AM
> >> To: Jakub Hrozek
> >> Cc: freeipa-users@redhat.com
> >> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local
> >> user account
> >>
> >> On Centos7.2 all patches applied I used the command:
> >> ipa-client-install --enable-dns-updates
> >>
> >> Rob
> >>
> >> 2016-02-04 16:45 GMT+01:00 Jakub Hrozek <jhro...@redhat.com>:
> >> > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote:
> >> >> Hello,
> >> >>
> >> >> I've noticed that the sudorule-add-runasuser no longer has en
> >> >> --external option
> >> >>
> >> >> What is the current method to add a local service account to a sud
> >> >> rule list so that users may run sudo as that service account (ie
> >> >> apache or jboss)
> >> >>
> >> >> Cheers
> >> >> Rob Verudijn
> >> >
> >> > I know I'm not answering your question but how did you configure
> >> > the client side earlier? Did you use the native/legacy sudo ldap driver?
> >> >
> >> > The reason I'm asking this is that sssd only supports users it
> >> > handles, so in the IPA case it only supports IPA users anyway..
> >> >
> >> > --
> >> > 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

-- 
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 client in DMZ

[Baird, Josh]

I believe the sssd clients will need to communicate directly with your AD 
domain controllers, unfortunately.  I wish there was a clean way around this, 
since we have a ton of DC's in our HUB site, and I don't really want to poke 
holes in the firewall(s) for all of them.  

Would someone from sssd/IPA mind chiming in here?  What exactly needs to be 
open?  What DNS record can we query to get the exact list of DC's that need to 
be available?  Is there a way to restrict the list of domain controllers that 
certain sssd clients need to communicate with (for scenarios like this)?

Thanks,

Josh

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Andy Thompson
> Sent: Tuesday, February 02, 2016 9:04 AM
> To: freeipa-users@redhat.com
> Subject: [Freeipa-users] freeipa client in DMZ
> 
> Are ports required to be open for a freeipa client in a DMZ to the AD DCs for
> trusted users to login?  I've got everything open to the IPA servers required
> and can lookup users and sudo rules and such but trusted users are not able
> to login.
> 
> Thanks
> 
> -andy
> 
> 
> 
> *** This communication may contain privileged and/or confidential
> information. It is intended solely for the use of the addressee. If you are 
> not
> the intended recipient, you are strictly prohibited from disclosing, copying,
> distributing or using any of this information. If you received this
> communication in error, please contact the sender immediately and destroy
> the material in its entirety, whether electronic or hard copy. ***
> 
> 
> --
> 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] 4.2 Packages for RHEL/CentOS 7.1

[Baird, Josh]

RHEL 7.2 went GA today.  

> On Nov 19, 2015, at 7:59 PM, Christopher Young  wrote:
> 
> I recall that original message about the packaging before RHEL 7.2 and
> how few of us expressed interest.  I believe I did respond to the
> positive that I could use these packages, but I certainly understand
> additional effort.  I just hate to be waiting on RH's cycle to get
> updates to one of the pieces of my infrastructure where features are
> in-demand and getting added more often.  I prefer my base server OS's
> to stay as stable as possible, but FreeIPA is an exception for me.  In
> any case, I appreciate the effort and the response.
> 
> Just so that I'm clear, this basically means that we should wait until
> the RHEL 7.2 release (and the following CentOS 7.2 release) before
> this will generally available?  I want to make sure I pay attention to
> that as it gets released.
> 
> Thanks,
> 
> Chris
> 
>> On Thu, Nov 12, 2015 at 3:45 AM, Alexander Bokovoy  
>> wrote:
>>> On Wed, 11 Nov 2015, Christopher Young wrote:
>>> 
>>> Do we know what the status of getting these packages prepped and into the
>>> mainstream repos (like EPEL, I suppose)?
>>> 
>>> I'm just curious as I try and keep my repos minimal on servers (for
>>> obvious
>>> reasons), but I would really like to begin testing/using the functionality
>>> in 4.2.
>> 
>> I believe EPEL's policy prevents you from packaging software which
>> exists in RHEL proper. FreeIPA 4.2 is coming with RHEL 7.2, it is
>> already published as part of RHEL 7.2 beta in September.
>> 
>> I want to remind  that during this summer I ran few queries here
>> (freeipa-users@) and elsewhere to solicit opinions whether people want
>> to have FreeIPA 4.2 packages available for CentOS before RHEL 7.2
>> release. Very few responses came back and there wasn't any convincing
>> feedback that would have justified additional effort to make the
>> repository and maintenance reasonable.
>> 
>> https://www.redhat.com/archives/freeipa-users/2015-July/msg00243.html
>> 
>> --
>> / 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

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

[Baird, Josh]

I'm also interested in how people are handling this - especially when using AD 
Trusts.

When using a trust, the IPA host not only has to communicate with IPA servers, 
but with potentially every AD domain controller in your HUB site.  For us, this 
is a large number of domain controllers which means we would need a large 
number of ACL's on our firewalls to permit the IPA DMZ client access to the AD 
domain controllers.

Any suggestions?

Thanks,

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Aly Khimji
Sent: Wednesday, October 07, 2015 1:12 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] FreeIPA DMZ topology

Hey guys,

Question for you, would having a replica be the ideal solution for authorizing 
hosts in a DMZ?

Do you have any use cases for DMZ access/authorization or topologies you can 
share for DMZ zones where FreeIPA is used?

Aly


-- 
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] Using NTP SRV records

[Baird, Josh]

You need to specify '--no-ntp' on 'ipa-client-install'

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of John Stein
Sent: Tuesday, July 07, 2015 7:38 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Using NTP SRV records

Hi,

I have an IPA server installed with --no-ntp, and created SRV records
_ntp._udp_.linux.john.comhttp://linux.john.com
pointing to my actual NTP servers. However, when I run ipa-client-install it is 
configured with the IPA server as an NTP server.

Am I missing something?

Thanks,
John
-- 
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 and external DNS

[Baird, Josh]

You should add your IPA zone as a slave on your 'external' DNS servers so they 
are able to resolve the IPA zone.

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Winfried de Heiden
Sent: Monday, May 18, 2015 10:10 AM
To: Freeipa-users
Subject: [Freeipa-users] AD-trust and external DNS

Hi all,

Creating an AD-trust works nicely. However, for some customers both AD and IPA 
don't have have DNS for their own, the use external DNS (Infoblox for example)

Now, is is possible to create an AD trust without a build-in (bind) IPA-DNS?

Thankz!

Winfried

-- 
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 4.1.4 DNS notifications not being sent to slaves

[Baird, Josh]

Is the PowerDNS slave in the NS RRSet for the IPA domain?  Unfortuantely, 
bind-dyndb-ldap does not support 'also-notify' which would allow us to send 
notifies each time a zone update occurs to slave servers that are not in the 
RRSet [1].  To compensate for this in my environment, I had to lower the 
'refresh' timer on the IPA zone.

[1] https://fedorahosted.org/bind-dyndb-ldap/ticket/152

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of nat...@nathanpeters.com
Sent: Friday, May 1, 2015 8:20 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] FreeIPA 4.1.4 DNS notifications not being sent to 
slaves

I have 2 FreeIPA 4.1.4 servers setup on CentOS 7 as replicas.

I also have another host running PowerDNS serving as a slave.
The FreeIPA servers are setup to allow transfers to the slave by IP.  When 
adding the zone, the slave transfered it properly.

However, when I update the zone in FreeIPA, although the serial number changes, 
in the /var/log/messages I only see an attempt to transfer to the second IPA 
server, and not the slave.  This is the only log entry :

May  2 01:06:56 dc1 named-pkcs11[5897]: zone mydomain.net/IN: sending notifies 
(serial 1430528817) May  2 01:06:57 dc1 named-pkcs11[5897]: client 
10.178.0.99#29832: received notify for zone 'mydomain.net'

I have restarted all services using ipactl restart several times.  I have also 
ensured that the slave hostname and IP are in FreeIPA DNS.  I have also added 
an NS entry pointing to the slave.

According to the FreeIPA manual, once that NS entry is added, any zone updates 
should trigger a notify, but still the only notifications go out to FreeIPA 
servers and nothing else.

Any idea how to fix this so FreeIPA notifies non IPA servers?  I'm pretty sure 
I've followed all the instructions to the letter on this one...


--
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] Slave DNS on FreeIPA replica

[Baird, Josh]

Yes, but you need to allow zone transfers to your non-IPA servers:

$ ipa dnszone-mod --allow-transfer=1.2.3.4 domain.com

(where 1.2.3.4 is the IP of your new slave and domain.com is the zone name you 
want to transfer)

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Christopher Young
Sent: Monday, April 06, 2015 7:02 PM
To: Rob Crittenden
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Slave DNS on FreeIPA replica

I clearly missed that.  Thanks for the clarification.  As far as adding 
additional DNS servers merely to slave the zones, is that more or less the same 
as configuring any other bind slave?

On Mon, Apr 6, 2015 at 3:15 PM, Rob Crittenden 
rcrit...@redhat.commailto:rcrit...@redhat.com wrote:
Christopher Young wrote:
 I have - what I believe to be - a couple of basic questions (I apologize
 in advance if these are answered elsewhere, though I've tried to do some
 searching ahead of time.):

 I recently added an IPA replica to an existing IPA server and noticed
 that everything appeared to succeed in the setup.  One observation is
 that DNS (bind) was not set up on this new host.  I was wondering if
 this is normal behavior, and if so, is there a set of instructions
 needed to add/create additional DNS servers for use with FreeIPA?

 Ideally, I would like to have DNS running on all IPA hosts.
 Additionally, I plan on adding a pair of caching/slave DNS servers
 running standing BIND on remote networks and was wondering what the
 procedure would be to slave those zones onto those.  Would that be the
 same as allowing the transfer from those IPs and treating them just like
 any other BIND slave for the appropriate zones?

 I appreciate the clarifications and all the effort that goes into this!
DNS and a CA are optional components in a replica. You can add them
using ipa-dns-install and ipa-ca-install respectively.

To install bind during the replica install process add the option
--setup-dns.

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] freeipa 4.x packages for RHEL?

[Baird, Josh]

FreeIPA 4 is currently available in RHEL 7.1.

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Steve Neuharth
Sent: Tuesday, March 31, 2015 10:02 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] freeipa 4.x packages for RHEL?

Hello,
We're currently running RHEL in production and would love to be using all the 
goodness that is FreeIPA 4 including certmonger for certificate management. I 
don't see any mention of 4.x packages available for RHEL in the mailing lists 
and I have run into problems using the 3.3 client packages on a 4.x realm.
When will 4.x packages be available for RHEL?
--steve

-- 
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] Error establishing trust with AD domain

[Baird, Josh]

Ok - I'll answer my own question.  I needed to establish the trust with the 
forest-root domain (domain.com), not the child domain.  I have verified using 
'ipa trustdomain-find' that I can see the child domain (ad.domain.com) now.

Sorry for the noise!

Thanks,

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Baird, Josh
Sent: Monday, March 09, 2015 5:06 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Error establishing trust with AD domain

Hi,

I have successfully established a trust in my lab environment running IPA 4.1 
(RHEL7.1) and a Windows 2008 R2 domain with Windows 2003 domain/forest 
functional levels.   I'm now trying to establish a trust with my production AD 
domain (same functional level).  The only difference is that my production 
domain (ad.domain.lan) is a child-domain of a forest named domain.lan.  There 
is no forest in my lab envrionment.  I'm getting the following error when 
running 'ipa trust-add':

# ipa trust-add --type ad ad.domain.lan --range-type=ipa-ad-trust --admin 
jbadmin --password
Active Directory domain administrator's password:
ipa: ERROR: Domain 'ad.domain.lan' is not a root domain for forest 'domain.lan'

Any ideas?

Thanks,

Josh

-- 
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] Error establishing trust with AD domain

[Baird, Josh]

Hi,

I have successfully established a trust in my lab environment running IPA 4.1 
(RHEL7.1) and a Windows 2008 R2 domain with Windows 2003 domain/forest 
functional levels.   I'm now trying to establish a trust with my production AD 
domain (same functional level).  The only difference is that my production 
domain (ad.domain.lan) is a child-domain of a forest named domain.lan.  There 
is no forest in my lab envrionment.  I'm getting the following error when 
running 'ipa trust-add':

# ipa trust-add --type ad ad.domain.lan --range-type=ipa-ad-trust --admin 
jbadmin --password
Active Directory domain administrator's password:
ipa: ERROR: Domain 'ad.domain.lan' is not a root domain for forest 'domain.lan'

Any ideas?

Thanks,

Josh

-- 
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] issues with secondary groups? (sssd)

[Baird, Josh]

There is active development on the puppet-ipaclient module [1].  You should see 
a new release in the next few days that adds better support for ipa4, exposes 
sssd options and more.

[1] https://forge.puppetlabs.com/stbenjam/ipaclient

We will be using this module to automate the client install on a group of ~500 
RHEL servers.

Thanks,

Josh

 -Original Message-
 From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
 boun...@redhat.com] On Behalf Of Jakub Hrozek
 Sent: Monday, March 02, 2015 7:26 AM
 To: Janelle
 Cc: James Shubin; freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] issues with secondary groups? (sssd)
 
 On Mon, Mar 02, 2015 at 04:09:34AM -0800, Janelle wrote:
  That was the point. The clients were not installed with IPA client install.
  I have 2000 clients and still working on a simple way to automate the client
 install with ansible or puppet. Currently just trying to get it working with
 simple sssd/ldap only auth.
 
 I would recommend against enrolling clients in any other way than with ipa-
 client-install.
 
 I've CC-ed James Shubin, who worked on automating client installs with
 Puppet (and Puppet-iting IPA in general), I wonder if there's some howto
 we can link to?
 
 --
 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] Real-time replication status (RFE)?

[Baird, Josh]

Hi,

I'm looking for an easy way to validate that all replication agreements are 
functioning correctly between all of my IPA masters and replicas.  I am aware 
that I can run 'ipa-replica-manage list -v' from each IPA master, but I was 
looking for something more centralized that could give me a replication health 
report for all masters/replicas.  Ideally, this type of feature would be 
exposed in the UI and would also include information or insight into the status 
of any IPA - AD trust relationships.

Am I missing a feature that already exists?  If not, is there something like 
this on the IPA roadmap?

Cheers,

Josh


-- 
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] Real-time replication status (RFE)?

[Baird, Josh]

That would be great, thanks!

Josh

 -Original Message-
 From: Innes, Duncan [mailto:duncan.in...@virginmoney.com]
 Sent: Thursday, February 05, 2015 11:34 AM
 To: Rob Crittenden; Baird, Josh; freeipa-users@redhat.com
 Subject: RE: [Freeipa-users] Real-time replication status (RFE)?
 
 The screen mockup in that ticket is based on a Perl script that I stuck in 
 cgi-bin
 to pull just those stats off each IPA server I have and display them.  Can 
 share
 the code if you're interested.
 
 D
 
 -Original Message-
 From: freeipa-users-boun...@redhat.com
 [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rob Crittenden
 Sent: 05 February 2015 14:19
 To: Baird, Josh; freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Real-time replication status (RFE)?
 
 Baird, Josh wrote:
  Hi,
 
  I'm looking for an easy way to validate that all replication
 agreements are functioning correctly between all of my IPA masters and
 replicas.  I am aware that I can run 'ipa-replica-manage list -v' from each 
 IPA
 master, but I was looking for something more centralized that could give me
 a replication health report for all masters/replicas.
 Ideally, this type of feature would be exposed in the UI and would also
 include information or insight into the status of any IPA - AD trust
 relationships.
 
  Am I missing a feature that already exists?  If not, is there
 something like this on the IPA roadmap?
 
 This is being tracked in https://fedorahosted.org/freeipa/ticket/4390
 
 It depends on some other work being done first.
 
 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
 
 This message has been checked for viruses and spam by the Virgin Money
 email scanning system powered by Messagelabs.
 
 This message has been checked for viruses and spam by the Virgin Money
 email scanning system powered by Messagelabs.
 
 This e-mail is intended to be confidential to the recipient. If you receive a
 copy in error, please inform the sender and then delete this message.
 
 Virgin Money plc - Registered in England and Wales (Company no. 6952311).
 Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL.
 Virgin Money plc is authorised by the Prudential Regulation Authority and
 regulated by the Financial Conduct Authority and the Prudential Regulation
 Authority.
 
 The following companies also trade as Virgin Money. They are both
 authorised and regulated by the Financial Conduct Authority, are registered
 in England and Wales and have their registered office at Jubilee House,
 Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial
 Service Limited (Company no. 3072766) and Virgin Money Unit Trust
 Managers Limited (Company no. 3000482).
 
 For further details of Virgin Money group companies please visit our website
 at virginmoney.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] Automount and home directory creation

[Baird, Josh]

The RHEL6/7 manuals say this:

Use a remote user who has limited permissions to create home directories and 
mount the share
on the IdM server as that user. Since the IdM server runs as an httpd process, 
it is possible to
use sudo or a similar program to grant limited access to the IdM server to 
create home
directories on the NFS server.

I suppose this may be one option that is worth investigating.

Thanks,

Josh

 -Original Message-
 From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
 boun...@redhat.com] On Behalf Of Dmitri Pal
 Sent: Tuesday, January 20, 2015 6:01 PM
 To: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Automount and home directory creation
 
 On 01/20/2015 05:40 PM, Baird, Josh wrote:
  Hi,
 
  I'm considering migrating to automounted home directories (via NFS), but
 would like to avoid having to manually create/provision the home directories
 on the NFS server.  This [1] blog covers the very topic, but I'm not sure that
 any progress was ever made.
 
  Does anyone have any ideas or suggestions?
 
  [1] -
  http://adam.younglogic.com/2011/06/automount-and-home-directory-
 creati
  on/
 
  Thanks,
 
  Josh
 
 
 Well... there is not simple solution and there was not much demand so it is
 sitting on the back burner.
 
 A help would be really appreciated to move this forward.
 
   --
 Thank you,
 Dmitri Pal
 
 Sr. Engineering Manager IdM portfolio
 Red Hat, Inc.
 
 --
 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] Automount and home directory creation

[Baird, Josh]

Hi,

I'm considering migrating to automounted home directories (via NFS), but would 
like to avoid having to manually create/provision the home directories on the 
NFS server.  This [1] blog covers the very topic, but I'm not sure that any 
progress was ever made.

Does anyone have any ideas or suggestions?

[1] - http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/

Thanks,

Josh


-- 
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] DNS Design for FreeIPA4

[Baird, Josh]

Hi,

We are currently piloting FreeIPA4 (RHEL 7.1 IdM) in our environment.  We plan 
on establishing a trust with AD at some point during the POC.  An overview of 
the current DNS design:

* FreeIPA runs integrated DNS (ie, ipa.domain.com)
* Servers in our environment (even once joined to IPA) continue to use our 
current non-IPA DNS infrastructure for name resolution
* Servers in our environment have hostnames in several other non-IPA domains 
(not ipa.domain.com)
* IPA DNS is configured to zone-transfer ipa.domain.com to our primary 
infrastructure non-IPA DNS servers
* IPA is configured to forward all non ipa.domain.com requests to our primary 
infrastructure non-IPA DNS servers
* ipa.domain.com DNS can be resolved from all non-IPA DNS servers since it is a 
slave on our primary non-IPA DNS servers
* IPA can resolve our Active Directory DNS (ad.domain.lan)
* Active Directory DNS can resolve IPA DNS (ipa.domain.com)

Is this a sensible design for DNS?  In this configuration, IPA does not appear 
to be creating DNS records in ipa.domain.com for the hosts that we add to IPA.  
This is presumably because the hosts themselves are in other domains (not 
ipa.domain.com) which are not controlled by IPA.  Is this going to cause 
problems?

We have a requirement to keep all servers in our environment using our primary 
non-IPA DNS servers for resolution.  It seemed logical to use IPA-integrated 
DNS just so IPA could manage the SRV/LDAP records automatically within the IPA 
zone.  

Any advice/tips/suggestions regarding this design would be greatly appreciated.

Thanks,

Josh


-- 
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] DNS Design for FreeIPA4

[Baird, Josh]

William,

I don't understand why I would have problems if AD DNS can resolve IPA dns, and 
IPA DNS can resolve AD DNS?

The DNS servers that my servers are using can resolve both AD and IPA.

Thanks,

Josh

 -Original Message-
 From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
 boun...@redhat.com] On Behalf Of William Muriithi
 Sent: Thursday, January 15, 2015 8:08 PM
 To: freeipa-users@redhat.com; freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] DNS Design for FreeIPA4
 
 ‎Josh,
 
 You will have problems if you go with below plan in my opinion. I used
 arrangements like the one you listed below when I used freeipa 2.2. This
 worked for me only when I had users hosted on freeipa. After upgrading to
 3.3 for trust, it became very unreliable and had to point the ipa clients to 
 ipa
 server for it to work reliably
 
 Especially if you plan to point them to AD, it wouldn't work as AD use dns for
 configuration just like ipa, do there will be conflict.
 
 William
 
 
 We are currently piloting FreeIPA4 (RHEL 7.1 IdM) in our environment. We
 plan on establishing a trust with AD at some point during the POC. An
 overview of the current DNS design:
 
 * FreeIPA runs integrated DNS (ie, ipa.domain.com)
 * Servers in our environment (even once joined to IPA) continue to use our
 current non-IPA DNS infrastructure for name resolution
 * Servers in our environment have hostnames in several other non-IPA
 domains (not ipa.domain.com)
 * IPA DNS is configured to zone-transfer ipa.domain.com to our primary
 infrwastructure non-IPA DNS servers
 * IPA is configured to forward all non ipa.domain.com requests to our
 primary infrastructure non-IPA DNS servers
 * ipa.domain.com DNS can be resolved from all non-IPA DNS servers since it
 is a slave on our primary non-IPA DNS servers
 * IPA can resolve our Active Directory DNS (ad.domain.lan)
 * Active Directory DNS can resolve IPA DNS (ipa.domain.com)
 
 Is this a sensible design for DNS? In this configuration, IPA does not appear
 to be creating DNS records in ipa.domain.com for the hosts that we add to
 IPA. This is presumably because the hosts themselves are in other domains
 (not ipa.domain.com) which are not controlled by IPA. Is this going to cause
 problems?
 
 We have a requirement to keep all servers in our environment using our
 primary non-IPA DNS servers for resolution. It seemed logical to use IPA-
 integrated DNS just so IPA could manage the SRV/LDAP records
 automatically within the IPA zone.
 
 Any advice/tips/suggestions regarding this design would be greatly
 appreciated.
 
 Thanks,
 
 Josh
 
 
 
 
 --
 
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users
 
 End of Freeipa-users Digest, Vol 78, Issue 62
 *
 
 --
 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] Configure also-notify for freeipa DNS zones

[Baird, Josh]

Hi,

The docs state this:

DNS slaves will transfer the whole zone periodically as is specified in zone's 
SOA record. DNS masters also send DNS NOTIFY messages to inform slaves about a 
change asynchronously.

I have a need to execute zone transfers from my IPA server(s) to non-IPA slaves 
and I would like the IPA servers to send notifies each time the zone is 
updated/reloaded (eg, the also-notify option in BIND).  Currently, the zone 
transfer is only executed once the refresh timer in the SOA expires.  I don't 
see an option within IPA to configure the BIND also-notify option.

How can I make my IPA DNS servers send notify's to my non-IPA slave servers so 
that zone transfers occur immediately after IPA zone updates?

Thanks,

Josh

-- 
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] ipa-client-install via Kickstart in RHEL7

[Baird, Josh]

Hi,

We are attempting to run ipa-client-install in the %post section of a Kickstart 
in order to join the host to an IPA domain (3.3/RHEL7 IdM).  We are using 
something like:

/usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U 
--no-ssh --no-sshd --no-ntp --domain=realm.com

The machine does indeed join the domain correctly, but the certmonger request 
fails.  Looking at the logs, we can see this:

2014-08-19T15:02:45Z DEBUG Starting external process
2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service
2014-08-19T15:02:45Z DEBUG Process finished, return code=0
2014-08-19T15:02:45Z DEBUG stdout=
2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request.

The error is occurring because the certmonger service fails to start.  This is 
because systemd is not able to manipulate services in a chrooted environment 
(ala the anaconda installation environment).  Prior to systemd, this would work 
fine as services could start normally via init in a chroot/%post.

Additionally, we see the error:

Unable to find 'admin' user with 'getent passwd ad...@domain.com'

Again, this is because systemd is unable to start sssd in the chrooted 
installation environment.  I'm wondering if anyone else has experienced these 
issues with systemd unable to start these required services during installation 
and what you did to work around them.  One option would be to move the 
ipa-client-install out of Kickstart and have Puppet join the host to the domain 
post-installation (after firstboot), but this isn't really ideal.

Any advice or suggestions would be appreciated.

Thanks,

Josh

-- 
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] Problems establishing a trust with AD

[Baird, Josh]

Hi,

I'm attempting to establish a trust between FreeIPA 3.3 and AD 2008 R2.  My IPA 
domain consists of two servers (one master and one replica).  I have verified 
that DNS is configured properly as the IPA domain can resolve AD and the AD 
domain can resolve IPA hosts.

On each IPA server, I performed the following:

$ yum install ipa-server-trust-ad samba-client
$ ipa-adtrust-install

On the main IPA server, I executed the following:

$ ipa trust-add --admin administrator --password

The output of this command suggests that establishing the trust was successful:

-
Added Active Directory trust for realm test.lan
-
  Realm name: test.lan
  Domain NetBIOS name: TEST
  Domain Security Identifier: S-1-5-21-2234298371-4032204425-1996979893
  SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, 
S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, 
S-1-5-11, S-1-5-12,
  S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, 
S-1-5-18, S-1-5-19, S-1-5-20
  SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, 
S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, 
S-1-5-11, S-1-5-12,
  S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, 
S-1-5-18, S-1-5-19, S-1-5-20
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  Trust status: Established and verified

Additionally, I can also see the IPA domain in Active Directory Domains and 
Trusts on the Windows side.  Next, I successfully requested a service ticket 
for the AD domain:

$ kvno cifs/vmxxenttest01.test@test.lan
cifs/vmxxenttest01.test@test.lan: kvno = 4
$ klist | grep TEST
08/20/2014 11:03:47  08/20/2014 21:03:47  cifs/vmxxenttest01.test@test.lan
08/20/2014 11:03:47  08/21/2014 11:00:30  krbtgt/test@qa-unix.domain.com

Next, I modified /etc/krb5.conf on both IDM servers (master and replica) and 
added the following to the [realms] section and restarted krb5kdc:

auth_to_local = RULE:[1:$1@$0](^.*@TEST.LAN$)s/@TEST.LAN/@TEST.LAN/
auth_to_local = DEFAULT

I also modified /etc/sssd/sssd.conf and added pac to services and 
subdomains_provider = ipa.

Next, I tried to validate the trust from the AD side using the Validate 
button in AD Domains and Trusts.  Once I click the 'Vaildate' button, I choose 
Yes, validate the incoming trust and specify the IPA admin account and 
password and get notified that the trust cannot be validated due to There are 
currently no logon servers available to service the logon requests.  It 
suggests that I reset the trust password, and I accept, but again it fails due 
to no logon servers.

I don't really see anything in the krb5kdc.log logs on the IPA servers.  Any 
ideas how to further troubleshoot this?

Thanks,

Josh


-- 
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] Local users/groups to IPA Transition

[Baird, Josh]

 So if I understand this right, you're planning on two back to back user
 migrations? First is local-FreeIPA, then eventually FreeIPA-AD? Are your
 current local users coincidentally the same as your current AD users?

Well - I will likely try to skip the Local - FreeIPA and just go directly to 
FreeIPA - AD.  My main question though still remains - do I force the same 
local UID/GIDs to the IPA/AD users?  I'm just looking for advice on local user 
to IPA migration strategies.

Josh

-- 
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] Local users/groups to IPA Transition

[Baird, Josh]

 I wouldn't recommend duplicating your users, pick one and use that. If you
 want to be able to manage your users, groups, HBAC, sudo, etc.
 centrally then you'll want the users in IPA. But if you leave them locally you
 may end up with corner case problems.
 
 If you *do* end up adding your local users to IPA then yeah, you've got a
 decision to make. Either your use the existing UID/GID which is probably fine
 (though you may want to look adding a local range) or you let IPA assign a
 new UID from its own range, then you have to quickly change file ownership
 on all enrolled systems.
 

Well, the users are definitely going to be in IPA (or AD via IPA).  However, 
they *will* exist in both IPA and locally during the migration period.  If they 
have the same UID/GIDs in both places (local and IPA), then I will need to 
prefer IPA to 'files' in nsswitch.conf.  The main reason I want to duplicate 
the local UID/GID's in IPA is to retain file permissions.

Josh

-- 
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] Local users/groups to IPA Transition

[Baird, Josh]

Hi,

We are evaluating RHEL7 IdM (FreeIPA 3.3) for identity management for our UNIX 
infrastructure.  All of our Linux hosts currently have standard and consistent 
UID/GIDs for at least all of our administrative users.  I'm looking for advice 
on how to migrate these users into IPA.

Since we already have consistent UID/GID numbering for our local users, would 
it be advisable to use these same UID/GIDs for the IPA users?  The local users 
and groups with the same UID/GIDs would still exist on the host during the IPA 
transition.  I assume that if we decided to do this, we would need to modify 
/etc/nsswitch.conf on each host so sss is queried before files for 
passwd/shadow/group.

Eventually we plan to configure a kerberos trust with our AD domain where we 
could configure these UID/GIDs via AD's POSIX UID/GID settings.

How have others handled local to IPA migrations?  Any advice or input would be 
greatly appreciated.

Thanks,

Josh

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