[Freeipa-users] SSSD, sudo and FQDNs

[Lachlan Musicman]

Hola,

We couldn't get sssd and sudo to work and discovered this on the SSSD
troubleshooting page:

https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO#Knownissues

Is this on the radar to be solved at all or is it unsolvable?

Cheers
L.
--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] File user and group ownership listings...

[Simpson Lachlan]

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Alexander Bokovoy
> Sent: Thursday, 19 May 2016 5:12 PM
> To: Lachlan Musicman
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] File user and group ownership listings...
> 
> On Thu, 19 May 2016, Lachlan Musicman wrote:
> >Now that groups are working as expected, we have noticed that when
> >listing a directory the user and group now have full domain qualifiers.
> >
> >This doesn't look great. We've also noticed that we now need to
> >
> >chown :group@subdomain filename
> >
> >(with default_domain_suffix set).
> >
> >
> >Is there a reason why when the group's name and ID is the same across
> >both domains, it can't be considered the same group for file ownership 
> >reasons?
> In POSIX systems user and group IDs are two different namespaces. We force
> so-called private groups to have the same ID as the user to simplify some of 
> hard
> identity mapping problems between POSIX and Windows environments. In
> Windows world security identifier (SID) namespace is the same for all objects.

Ah, ok then. Thanks!

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] File user and group ownership listings...

[Simpson Lachlan]

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Thursday, 19 May 2016 5:22 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] File user and group ownership listings...
> 
> On Thu, May 19, 2016 at 04:33:45PM +1000, Lachlan Musicman wrote:
> > Now that groups are working as expected, we have noticed that when
> > listing a directory the user and group now have full domain qualifiers.
> >
> > This doesn't look great. We've also noticed that we now need to
> >
> > chown :group@subdomain filename
> 
> This is something that will work in 7.3. There is currently a limitation in 
> our cache
> that forces us to use fully-qualified names for users from trusted domains.

Fantastic. Thanks for all the hard work!


Cheers
L.  

This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Mostly working trust, SSH failure

[Erik Mackdanz]

Hello,

I've set up a one-way trust to an Active Directory domain.  Things
seem to roughly work, but something's missing.

Can any kind soul spot a problem with my configuration, or advise on
how to further troubleshoot?

Facts:

- An AD user gets 'Access denied' when SSH'ing by password to the
  FreeIPA host.  This is my concern.

- This AD user has not been locked out.

- getent passwd succeeds for the AD user

- A FreeIPA user can successfully SSH by password to the same FreeIPA
  host.

- That FreeIPA user can then successfully kinit as the AD user (the
  same AD user denied above)

- HBAC is set to the default allow_all rule, which is enabled.
  Running the HBAC Test tool on the AD user confirms that they are
  authorized for sshd.

This tells me something is awry in sssd.conf or sshd_config or pam.d
or HBAC.

Thanks,
Erik

I've got sssd debug to 9.  Here's some output:


(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[be_fo_reset_svc] (0x1000): Resetting all servers in service
na.bazzlegroup.com
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[set_srv_data_status] (0x0100): Marking SRV lookup of service
'na.bazzlegroup.com' as 'neutra
l'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[set_server_common_status] (0x0100): Marking server
'deda9w1004.na.bazzlegroup.com' as 'name
not resolved'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[fo_set_port_status] (0x0100): Marking port 389 of server
'deda9w1004.na.bazzlegroup.com' as
'neutral'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[fo_set_port_status] (0x0400): Marking port 389 of duplicate server
'deda9w1004.na.bazzlegrou
p.com' as 'neutral'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[set_srv_data_status] (0x0100): Marking SRV lookup of service
'na.bazzlegroup.com' as 'neutra
l'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[set_server_common_status] (0x0100): Marking server
'usbe9w2003.na.bazzlegroup.com' as 'name
not resolved'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[fo_set_port_status] (0x0100): Marking port 389 of server
'usbe9w2003.na.bazzlegroup.com' as
'neutral'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[fo_set_port_status] (0x0400): Marking port 389 of duplicate server
'usbe9w2003.na.bazzlegrou
p.com' as 'neutral'
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[be_mark_dom_offline] (0x1000): Marking subdomain na.bazzlegroup.com
offline
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[be_mark_subdom_offline] (0x4000): Subdomain already inactive
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed:
[1432158262]: Subdoma
in is inactive.
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed:
1432158262
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[sdap_id_op_destroy] (0x4000): releasing operation connection
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[ipa_account_info_error_text] (0x0020): Bug: dp_error is OK on failed
request
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[acctinfo_callback] (0x0100): Request processed. Returned
3,1432158262,Account info lookup f
ailed
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[sbus_dispatch] (0x4000): dbus conn: 0x7f3bf48f92c0
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[sbus_dispatch] (0x4000): Dispatching.
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[sbus_message_handler] (0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.pamH
andler on path /org/freedesktop/sssd/dataprovider
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[be_req_set_domain] (0x0400): Changing request domain from
[platform.schlitz] to [na.bazzlegroup.com]
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[be_pam_handler] (0x0100): Got request with the following data
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[pam_print_data] (0x0100): command: PAM_AUTHENTICATE
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[pam_print_data] (0x0100): domain: na.bazzlegroup.com
(Thu May 19 20:43:34 2016) [sssd[be[platform.schlitz]]]
[pam_print_data] (0x0100): user: mr...@na.bazzlegroup.com
(Thu May 19 20:43:34 2016) 

[Freeipa-users] AD membership realmd way + samba?

[lejeczek]

hi users/devs

I've poked around samba list but was suggested to ask sssd 
people, I thought IPA's might know as well.


Having joined AD with realm - can samba take advantage of 
this membership? And if so then to what extent?


many thanks,

L.

--
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] LDAP server failover via altServer attribute?

[Guillermo Fuentes]

Hello all,

As OS X allows LDAP server failover via the altServer attribute (RFC4512)
from RootDSE, it would be great to be able to configure our Macs to connect
to a single FreeIPA server and add other FreeIPA servers as multiple
altServer values.
The current schema doesn't seem to support adding this attribute.
Can this be done in a way I'm missing?

Thanks in advance!

GUILLERMO FUENTES
SR. SYSTEMS ADMINISTRATOR

561-880-2998 x1337

guillermo.fuen...@modmed.com

[image: [ Modernizing Medicine ]] 
[image: [ Facebook ]]  [image:
[ LinkedIn ]]  [image:
[ YouTube ]]  [image: [
Twitter ]]  [image: [ Blog ]]
 [image: [ Instagram ]]

-- 
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] authconfig vs ipa-client-install

[Martin Kosek]

On 05/19/2016 04:12 PM, lejeczek wrote:
> hi evebody
> 
> I'd like to ask how does, what ipa installation does ot a box, relate to
> authconfig?
> 
> I am specifically thinking of the fact that authconfig does not indicate that
> IPAv2 is used, on a box which is IPA member/client.
> 
> Is it because it is for some older IPA, that "v2"? If yes, then should 
> authconf
> not reflect somehow that IPA is configured and used?

The IPAv2 related options in authconfig are rather outdated and will be removed
in future (we are having all sort of discussions what to do with authconfig).

Please simply use ipa-client-install if you are joining IPA. If you are joining
AD, use realmd. If you are connecting to some other Identity system, you can
use authconfig (and probably just enable SSSD) or edit PAM in the worst case.

There is some information in this doc:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_Authentication.html#configuring-auth-with-idm

HTH,
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] How does one authenticate Windows login against IPA

[John Meyers]

(apologize for possible double post)

Can you share the details of how you managed to this with FreeIPA (even
if it includes kadmin.local work)?  Many thanks!


On 5/18/16 6:03 PM, Coy Hile wrote:
> When I've done this in the past, I used mit directly, not IPA. I set up a one 
> way trust, then used "shadow objects" for users mapped using 
> alternateSecurityID. I've setup the same one way trust testing with freeipa, 
> but unfortunately I had to use kadmin.local to do it. I don't know that 
> that's actually supported. Simo?
>
> -c
>
> Sent from my iPad
>
>> On May 18, 2016, at 17:19, John Meyers  wrote:
>>
>> All,
>>
>> FreeIPA as we've discovered has some wonderful Windows integration
>> capability, but it is all predicated on Windows AD being the
>> authoritative source of user information.  2-Way trusts are great, but
>> they only work for kerberotized applications, not native Windows rights
>> (that would require FreeIPA to act as global catalog as I learned from
>> Alexander).  The winsync capability does not, as it turns out, sync
>> native IPA users to AD.
>>
>> The million dollar question is if you are 90% Linux shop and FreeIPA is
>> your authoritative user repository (AD is a blank slate), how do you
>> perform local Windows login authentication for the 10% of Windows
>> machines against FreeIPA?
>>
>> Thank you all!
>>
>> 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

-- 
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] authconfig vs ipa-client-install

[lejeczek]

hi evebody

I'd like to ask how does, what ipa installation does ot a 
box, relate to authconfig?


I am specifically thinking of the fact that authconfig does 
not indicate that IPAv2 is used, on a box which is IPA 
member/client.


Is it because it is for some older IPA, that "v2"? If yes, 
then should authconf not reflect somehow that IPA is 
configured and used?


many thanks.

L.

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

Re: [Freeipa-users] How does one authenticate Windows login against IPA

[Coy Hile]

Right, you have some process that creates the shadow accounts with a random, 
unknown, unused pass. This assumes you have some workflow for provisioning 
rather than doing ad hoc ipa user add as a human.

Sent from my iPad

> On May 18, 2016, at 23:20, John Meyers  wrote:
> 
> Even if you get that to work, you are still stuck with same issue
> discussed earlier in this thread -- you need to have a Windows account,
> either local or AD, to be able to login and grant rights against.  pGina
> just handles the authentication part.  The only way to do either a 1-way
> Kerberos trust (AD->IPA) or pGina is to somehow sync native IPA users to
> AD (or Samba AD) to create the "shadow account"?  Winsync will not do this.
> 
> 
> 
>> On 5/18/16 7:49 PM, Michael ORourke wrote:
>> What about using the pGina project on the Windows side?
>> 
>> Reference:
>> http://blog.zwiegnet.com/linux-server/configure-pgina-windows-7-openldap-authentication/
>> 
>> -Mike
>> 
>> -Original Message-
>>> From: John Meyers 
>>> Sent: May 18, 2016 5:19 PM
>>> To: freeipa-users@redhat.com
>>> Subject: [Freeipa-users] How does one authenticate Windows login against IPA
>>> 
>>> All,
>>> 
>>> FreeIPA as we've discovered has some wonderful Windows integration
>>> capability, but it is all predicated on Windows AD being the
>>> authoritative source of user information.  2-Way trusts are great, but
>>> they only work for kerberotized applications, not native Windows rights
>>> (that would require FreeIPA to act as global catalog as I learned from
>>> Alexander).  The winsync capability does not, as it turns out, sync
>>> native IPA users to AD.
>>> 
>>> The million dollar question is if you are 90% Linux shop and FreeIPA is
>>> your authoritative user repository (AD is a blank slate), how do you
>>> perform local Windows login authentication for the 10% of Windows
>>> machines against FreeIPA?
>>> 
>>> Thank you all!
>>> 
>>> 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
> 
> 
> 
> -- 
> 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] Changing spec.page_length?

[Martin Kosek]

On 05/17/2016 01:54 AM, Jeffery Harrell wrote:
> Is there a “soft” way to change the number of rows in tables like the hosts 
> and 
> DNS records search facets? I think I’d happily trade a little interactivity 
> when 
> going from one facet to another for the ability to see four or five times as 
> much information on a single screen at once. I get that I can write a 
> JavaScript 
> mod that pokes into the individual tables and modifies spec.page_length, but 
> is 
> there an easier way? A setting somewhere maybe? The source code suggests the 
> answer is no but I figured it couldn’t hurt to ask.

There is no such nice way in FreeIPA currently (as you have found out). The
best you can do now is writing a UI plugin (as you have also found out).

But you can sign to the respective RFE and watch the progress or even provide
patches if you are JavaScript savvy:

https://fedorahosted.org/freeipa/ticket/5742

Martin

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

[Freeipa-users] Renewal of new cert concept

[barrykfl]

Hi:

As stated in the guidline online.../root/ipa.crt is the server cert
generated by 3rd patry CA ? or the CA cert itself that need to pair with
server cert later. thx


Give the CSR to your external CA and have them issue you a new certificate.
We assume that the resulting certificate is saved into the /root/ipa.crt
file. We also assume that the /root/external-ca.pem file contains the
external CA certificate chain in the PEM format. The renewal needs to be
done on the IdM CA designated for managing renewals. One way to identify
the first-installed IdM server is to see if the value for subsystem.select
is New:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html
-- 
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] Advice sought on monitoring freeipa status

[Prashant Bapat]

For the replication issues please see
http://directory.fedoraproject.org/docs/389ds/howto/howto-replicationmonitoring.html

This has a perl script that you can use.

As for the authentication of the user monitoring replication, we thought
about it and ended up allowing anonymous reads on the replication status.
Thus you don't store any user/password at all.

In addition to this, we use Monit heavily. Its pretty flexible.

--Prashant

On 18 May 2016 at 15:38, Roderick Johnstone  wrote:

> Hi
>
> I'm trying to set up some monitoring of our freeipa installation. To start
> with, I'd like to know eg:
>
> 1) If replication stopped
>
> 2) Whether the ldap datatbases on replicas are inconsistent with each
> other.
>
> We have RHEL7 freeipa servers and RHEL6 and RHEL7 clients, all with latest
> distribution packages.
>
> I see a number of pages at www.ipa.org about monitoring freeipa in
> various ways, but I'm not sure any were actually implemented yet.
>
> Then I found this: https://github.com/peterpakos/ipa_check_consistency
> which looks useful but seems to require a plain text password for a
> privileged ldap account to be embedded in a file, which is less than ideal.
>
> So, I was wondering, as a stop gap, whether its possible to control the
> server that the ipa commands talk to at the command line?
>
> One could then run a cron job to iterate through the servers and compare
> various outputs from ipa commands. However, the ipa man page suggests the
> ipa command will go for either the server explicitly set in
> /etc/ipa/default.conf or if unavailable use those set in the DNS _SRV_
> records.
>
> Maybe there is a better way to do this that I missed altogether?
>
> Roderick Johnstone
>
> --
> 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] File user and group ownership listings...

[Jakub Hrozek]

On Thu, May 19, 2016 at 04:33:45PM +1000, Lachlan Musicman wrote:
> Now that groups are working as expected, we have noticed that when listing
> a directory the user and group now have full domain qualifiers.
> 
> This doesn't look great. We've also noticed that we now need to
> 
> chown :group@subdomain filename

This is something that will work in 7.3. There is currently a limitation
in our cache that forces us to use fully-qualified names for users from
trusted domains.

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

Re: [Freeipa-users] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Wed, May 18, 2016 at 11:17:05PM +, Simpson Lachlan wrote:
> > -Original Message-
> > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> > boun...@redhat.com] On Behalf Of Jakub Hrozek
> > Sent: Wednesday, 18 May 2016 5:40 PM
> > To: freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] HBAC access denied, all AD groups not detected
> > 
> > On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote:
> > > Hmmm, I also now see
> > >
> > > https://fedorahosted.org/sssd/ticket/2642
> > > and
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1217127
> > >
> > > Versions being run:
> > >
> > > sssd-client-1.13.0-40.el7_2.4.x86_64
> > > sssd-ad-1.13.0-40.el7_2.4.x86_64
> > > sssd-proxy-1.13.0-40.el7_2.4.x86_64
> > > sssd-1.13.0-40.el7_2.4.x86_64
> > > sssd-common-1.13.0-40.el7_2.4.x86_64
> > > sssd-common-pac-1.13.0-40.el7_2.4.x86_64
> > > sssd-ipa-1.13.0-40.el7_2.4.x86_64
> > > sssd-ldap-1.13.0-40.el7_2.4.x86_64
> > > python-sssdconfig-1.13.0-40.el7_2.4.noarch
> > > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
> > > sssd-krb5-1.13.0-40.el7_2.4.x86_64
> > >
> > > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64
> > 
> > The reason I asked about the server versions is
> > https://bugzilla.redhat.com/show_bug.cgi?id=1304333
> > 
> > I'm not too familiar with how the centos versioning works, can you check if 
> > that
> > bug is mentioned in the rpm changelog?
> 
> 
> "You are not authorized to access bug #1304333." :(
> This email (including any attachments or links) may contain 
> confidential and/or legally privileged information and is 
> intended only to be read or used by the addressee.  If you 
> are not the intended addressee, any use, distribution, 
> disclosure or copying of this email is strictly 
> prohibited.  
> Confidentiality and legal privilege attached to this email 
> (including any attachments) are not waived or lost by 
> reason of its mistaken delivery to you.
> If you have received this email in error, please delete it 
> and notify us immediately by telephone or email.  Peter 
> MacCallum Cancer Centre provides no guarantee that this 
> transmission is free of virus or that it has not been 
> intercepted or altered and will not be liable for any delay 
> in its receipt.

Ah, sorry, there must have been some private customer information in the
bugzilla. Here is the corresponding upstream ticket:
https://fedorahosted.org/freeipa/ticket/5573

-- 
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] File user and group ownership listings...

[Alexander Bokovoy]

On Thu, 19 May 2016, Lachlan Musicman wrote:

Now that groups are working as expected, we have noticed that when listing
a directory the user and group now have full domain qualifiers.

This doesn't look great. We've also noticed that we now need to

chown :group@subdomain filename

(with default_domain_suffix set).


Is there a reason why when the group's name and ID is the same across both
domains, it can't be considered the same group for file ownership reasons?

In POSIX systems user and group IDs are two different namespaces. We
force so-called private groups to have the same ID as the user to
simplify some of hard identity mapping problems between POSIX and
Windows environments. In Windows world security identifier (SID)
namespace is the same for all objects.

--
/ Alexander Bokovoy

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

[Freeipa-users] File user and group ownership listings...

[Lachlan Musicman]

Now that groups are working as expected, we have noticed that when listing
a directory the user and group now have full domain qualifiers.

This doesn't look great. We've also noticed that we now need to

chown :group@subdomain filename

(with default_domain_suffix set).


Is there a reason why when the group's name and ID is the same across both
domains, it can't be considered the same group for file ownership reasons?


cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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 group membership

[Simpson Lachlan]

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Alexander Bokovoy
> Sent: Thursday, 19 May 2016 4:07 PM
> To: Lachlan Musicman
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] AD group membership
> 
> On Thu, 19 May 2016, Lachlan Musicman wrote:
> >Hi,
> >
> >We seem to have some progress, after reading this blog post about sssd
> >performance tuning.
> >
> >https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-la
> >rge-ipa-ad-trust-deployments/
> >
> >So now we see that on the FreeIPA server, everything is stable and
> >always produces the results we expect with regard to users and group
> membership.
> >It's also a bit speedier, which is nice.
> >
> >Unfortunately, on the clients, we are still seeing groups "disappearing"
> >occasionally,
> You've been told in another thread to upgrade IPA and SSSD packages to what is
> in CentOS 7 updates. There was recently (May 12th) a release of RHEL 7.2.4
> updates which CentOS already picked up. This release included fixes to
> incomplete group membership you mention.


Yes - it seems to be working and stable, even post reboot. Thanks for your help.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Advise on the best way to configure the following

[pgb205]

We have:AD->winsync->FIPA1<->replica<->FIPA2etc to multiple other replicas from 
FIPA1

What we want is to establish separate set of FIPA replicas which wold still 
have information from AD and yet would not 'pollute' the FIPA1/FIPA2 replicas 
above.
So far we have considered following options:1. Set up new FIPA3 replica to grab 
its information from FIPA1.This didn't work as two-way-trust would replicate 
'bad' information from FIPA3 back to FIPA1/2
2. One way trust between replicas.Somehow establish one way replication from 
FIPA1->FIPA3. 'Good' information gets to FIPA3. But new additions on FIPA3 
won't make it back to 'clean' environment.From reading posts on the list this 
is impossible. 
3. Setup separate winsync 'channels' from AD directly to FIPA3. Ie 
AD->winsync->FIPA3.The problem with this is winsync of user accounts is 
possible, but password sync requires there to be only one point of contact 
between AD domain and FIPA domain.That is all AD controllers contact one and 
only one FIPA controller using passsync utility. So there is no way (if I 
understand correctly) to do:AD->sync->FIPA1      ->sync->FIPA3
If my understanding above is correct what would be the correct way of setting 
up separate FIPA environments, sourced from the same AD domain and to replicate 
both users and passwords?
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

Re: [Freeipa-users] How does one authenticate Windows login against IPA

[Alexander Bokovoy]

On Wed, 18 May 2016, John Meyers wrote:

All,

FreeIPA as we've discovered has some wonderful Windows integration
capability, but it is all predicated on Windows AD being the
authoritative source of user information.  2-Way trusts are great, but
they only work for kerberotized applications, not native Windows rights
(that would require FreeIPA to act as global catalog as I learned from
Alexander).  The winsync capability does not, as it turns out, sync
native IPA users to AD.

The million dollar question is if you are 90% Linux shop and FreeIPA is
your authoritative user repository (AD is a blank slate), how do you
perform local Windows login authentication for the 10% of Windows
machines against FreeIPA?

As I said before, we currently don't have answer to this question.
Development work still continues. Some people were able to do logins
with 'REALM\Username' but then assigning permissions does not work
anyway in Windows due to lack of GC support on IPA side.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] AD group membership

[Alexander Bokovoy]

On Thu, 19 May 2016, Lachlan Musicman wrote:

Hi,

We seem to have some progress, after reading this blog post about sssd
performance tuning.

https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

So now we see that on the FreeIPA server, everything is stable and always
produces the results we expect with regard to users and group membership.
It's also a bit speedier, which is nice.

Unfortunately, on the clients, we are still seeing groups "disappearing"
occasionally,

You've been told in another thread to upgrade IPA and SSSD packages to
what is in CentOS 7 updates. There was recently (May 12th) a release of
RHEL 7.2.4 updates which CentOS already picked up. This release included
fixes to incomplete group membership you mention.

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