Re: [Freeipa-users] sssd options ignored?

2015-03-18 Thread Gould, Joshua


On 3/18/15, 3:55 AM, Sumit Bose sb...@redhat.com wrote:

On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote:
 On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote:
  On Tue, 17 Mar 2015, Gould, Joshua wrote:

  /etc/sssd/sssd.conf:
  [domain/test.osuwmc]
  ldap_idmap_range_min = 10
  ldap_idmap_range_size = 90
  There is something completely broken here.
 
 Yes, the sssd.conf configuration :-)
 
 SSSD will not even read this sssd.conf section, it is just ignored. The
 subdomains are mostly auto-configured, just with several exceptions
 (like subdomain_homedir) where we read the subdomain config from the
 main domain config.
 
  You *shouldn't* need to add a
  separate domain section for any of the domains coming over the forest
  trust link path _at_all_. SSSD automatically derives all needed
  parameters for them via its IPA providers for the primary IPA domain.
  
  Jakub, what is going on?
 
 I would prefer if also Sumit can add his opinon since he authored the ID
 mapping code.

as Alexander said in the other thread, only the IPA domain should be
configured if you want to use IPA and trust. AD domains will be
discovered and ranges will be configured on the IPA server side and IPA
clients will get all information about trusted AD domains from the IPA
server.

So, please remove the section for the AD completely from sssd.conf.

I¹ll be happy to remove the AD section from the sssd.conf file and test
but I think there¹s more going on. The AD section was generated from the
IPA client install. I never manually added anything other than ³pac² to
the services line under the [sssd] section and the two ldap_idmap_range
options. 



-- 
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] sssd options ignored?

2015-03-18 Thread Jakub Hrozek
On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote:
 On Tue, 17 Mar 2015, Gould, Joshua wrote:
 I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need
 to match whats in ipa idrange-find --all for the AD domain.
 
 # ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0
 Range name: TEST.OSUWMC_id_range
 
 Modified ID range TEST.OSUWMC_id_range
 
 Range name: TEST.OSUWMC_id_range
 First Posix ID of the range: 10
 Number of IDs in the range: 90
 First RID of the corresponding RID range: 0
 Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810
 Range type: Active Directory domain range
 
 
 /etc/sssd/sssd.conf:
 [domain/test.osuwmc]
 ldap_idmap_range_min = 10
 ldap_idmap_range_size = 90
 There is something completely broken here.

Yes, the sssd.conf configuration :-)

SSSD will not even read this sssd.conf section, it is just ignored. The
subdomains are mostly auto-configured, just with several exceptions
(like subdomain_homedir) where we read the subdomain config from the
main domain config.

 You *shouldn't* need to add a
 separate domain section for any of the domains coming over the forest
 trust link path _at_all_. SSSD automatically derives all needed
 parameters for them via its IPA providers for the primary IPA domain.
 
 Jakub, what is going on?

I would prefer if also Sumit can add his opinon since he authored the ID
mapping code.

But here's how I see it - since you use 'external ID mapping', then you
should just rely on the properties from the server. The only action to
take on the client side is to purge the sssd cache on the clients if the
ID mapping changes, because currently SSSD doesn't handle ID changes.

And because gracefully handling ID changes is not planned even for the
next version (1.13), I wonder if it makes sense to add a warning after
idrange-mod command is run that it's preferable to clean the caches? We
might also want to add some kind of simple CLI tool (sss_delcache?) so
that admins don't have to learn where are the caches stored.

-- 
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] sssd options ignored?

2015-03-18 Thread Sumit Bose
On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote:
 On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote:
  On Tue, 17 Mar 2015, Gould, Joshua wrote:
  I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need
  to match whats in ipa idrange-find --all for the AD domain.
  
  # ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0
  Range name: TEST.OSUWMC_id_range
  
  Modified ID range TEST.OSUWMC_id_range
  
  Range name: TEST.OSUWMC_id_range
  First Posix ID of the range: 10
  Number of IDs in the range: 90
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810
  Range type: Active Directory domain range
  
  
  /etc/sssd/sssd.conf:
  [domain/test.osuwmc]
  ldap_idmap_range_min = 10
  ldap_idmap_range_size = 90
  There is something completely broken here.
 
 Yes, the sssd.conf configuration :-)
 
 SSSD will not even read this sssd.conf section, it is just ignored. The
 subdomains are mostly auto-configured, just with several exceptions
 (like subdomain_homedir) where we read the subdomain config from the
 main domain config.
 
  You *shouldn't* need to add a
  separate domain section for any of the domains coming over the forest
  trust link path _at_all_. SSSD automatically derives all needed
  parameters for them via its IPA providers for the primary IPA domain.
  
  Jakub, what is going on?
 
 I would prefer if also Sumit can add his opinon since he authored the ID
 mapping code.

as Alexander said in the other thread, only the IPA domain should be
configured if you want to use IPA and trust. AD domains will be
discovered and ranges will be configured on the IPA server side and IPA
clients will get all information about trusted AD domains from the IPA
server.

So, please remove the section for the AD completely from sssd.conf.

HTH

bye,
Sumit
 
 But here's how I see it - since you use 'external ID mapping', then you
 should just rely on the properties from the server. The only action to
 take on the client side is to purge the sssd cache on the clients if the
 ID mapping changes, because currently SSSD doesn't handle ID changes.
 
 And because gracefully handling ID changes is not planned even for the
 next version (1.13), I wonder if it makes sense to add a warning after
 idrange-mod command is run that it's preferable to clean the caches? We
 might also want to add some kind of simple CLI tool (sss_delcache?) so
 that admins don't have to learn where are the caches stored.
 
 -- 
 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] sssd options ignored?

2015-03-18 Thread Alexander Bokovoy

On Wed, 18 Mar 2015, Gould, Joshua wrote:



On 3/18/15, 3:55 AM, Sumit Bose sb...@redhat.com wrote:


On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote:

On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote:
 On Tue, 17 Mar 2015, Gould, Joshua wrote:

 /etc/sssd/sssd.conf:
 [domain/test.osuwmc]
 ldap_idmap_range_min = 10
 ldap_idmap_range_size = 90
 There is something completely broken here.

Yes, the sssd.conf configuration :-)

SSSD will not even read this sssd.conf section, it is just ignored. The
subdomains are mostly auto-configured, just with several exceptions
(like subdomain_homedir) where we read the subdomain config from the
main domain config.

 You *shouldn't* need to add a
 separate domain section for any of the domains coming over the forest
 trust link path _at_all_. SSSD automatically derives all needed
 parameters for them via its IPA providers for the primary IPA domain.

 Jakub, what is going on?

I would prefer if also Sumit can add his opinon since he authored the ID
mapping code.


as Alexander said in the other thread, only the IPA domain should be
configured if you want to use IPA and trust. AD domains will be
discovered and ranges will be configured on the IPA server side and IPA
clients will get all information about trusted AD domains from the IPA
server.

So, please remove the section for the AD completely from sssd.conf.


I¹ll be happy to remove the AD section from the sssd.conf file and test
but I think there¹s more going on. The AD section was generated from the
IPA client install. I never manually added anything other than ³pac² to
the services line under the [sssd] section and the two ldap_idmap_range
options.

Show your /var/log/ipaclient-install.log. ipa-client-install has no
support to generate sections for AD at all. 


--
/ 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] sssd options ignored?

2015-03-18 Thread Alexander Bokovoy

On Wed, 18 Mar 2015, Gould, Joshua wrote:

On 3/18/15, 4:28 AM, Alexander Bokovoy aboko...@redhat.com wrote:


On Wed, 18 Mar 2015, Gould, Joshua wrote:



I¹ll be happy to remove the AD section from the sssd.conf file and test
but I think there¹s more going on. The AD section was generated from the
IPA client install. I never manually added anything other than ³pac² to
the services line under the [sssd] section and the two ldap_idmap_range
options.

Show your /var/log/ipaclient-install.log. ipa-client-install has no
support to generate sections for AD at all.


I think then it would have to be the “ipa trust-add” command which
generates those sections then? The command that I used was:

No, it is not. We don't have *any* code that could have generated that
section in FreeIPA.



# ipa trust-add --type=ad TEST.OSUWMC ―-admin=farus ―password
--range-type=ipa-ad-trust
Active Directory domain administrator's password:
ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most
likely it is a DNS or firewall issue


The trust was created even with that error message and seems to work.

Do you get something like

$ kdestroy -A
$ kinit admin
$ kvno -S cifs hostname of AD DC
$ klist -ef

working?

--
/ 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] sssd options ignored?

2015-03-18 Thread Gould, Joshua


On 3/18/15, 9:48 AM, Alexander Bokovoy aboko...@redhat.com wrote:

On Wed, 18 Mar 2015, Gould, Joshua wrote:
On 3/18/15, 4:28 AM, Alexander Bokovoy aboko...@redhat.com wrote:

On Wed, 18 Mar 2015, Gould, Joshua wrote:


I¹ll be happy to remove the AD section from the sssd.conf file and test
but I think there¹s more going on. The AD section was generated from
the
IPA client install. I never manually added anything other than ³pac² to
the services line under the [sssd] section and the two ldap_idmap_range
options.
Show your /var/log/ipaclient-install.log. ipa-client-install has no
support to generate sections for AD at all.

I think then it would have to be the “ipa trust-add” command which
generates those sections then? The command that I used was:
No, it is not. We don't have *any* code that could have generated that
section in FreeIPA.

Since we’re still in the test phase, I can fairly easily set things up
again. It will help me to improve my own documentation for how things are
setup in test and how I can set things up in production. When I do that, I
can look at the sssd.conf after each step and see where it gets modified
and let you know. Like I said, I never created the domain section, but I
did add the debugging statement, the range options and the option for pac.


# ipa trust-add --type=ad TEST.OSUWMC ―-admin=farus ―password
--range-type=ipa-ad-trust
Active Directory domain administrator's password:
ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most
likely it is a DNS or firewall issue


The trust was created even with that error message and seems to work.
Do you get something like

$ kdestroy -A
$ kinit admin
$ kvno -S cifs hostname of AD DC
$ klist -ef

working?

All of those work even with the error when initially creating the trust.
We basically treated the error as cosmetic since everything else seems to
work.

[goul09@mid-ipa-vp01 ~]$ kdestroy
kdestroy: No credentials cache found while destroying cache
[goul09@mid-ipa-vp01 ~]$ kinit admin
Password for ad...@unix.test.OSUWMC:
[goul09@mid-ipa-vp01 ~]$ kvno -S cifs svr-addc-vt01.test.osuwmc
cifs/svr-addc-vt01.test.osuwmc@TEST.OSUWMC: kvno = 16
[goul09@mid-ipa-vp01 ~]$ klist -ef
Ticket cache: FILE:/tmp/krb5cc_998
Default principal: ad...@unix.test.OSUWMC

Valid starting   Expires  Service principal
03/18/2015 10:15:28  03/19/2015 10:15:25
krbtgt/unix.test.osu...@unix.test.OSUWMC
Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96
03/18/2015 10:16:08  03/19/2015 10:15:25
krbtgt/test.osu...@unix.test.OSUWMC
Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96
03/18/2015 10:15:46  03/18/2015 20:15:46
cifs/svr-addc-vt01.test.osuwmc@TEST.OSUWMC
Flags: FA, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96
[goul09@mid-ipa-vp01 ~]$


-- 
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] sssd options ignored?

2015-03-18 Thread Alexander Bokovoy

On Tue, 17 Mar 2015, Gould, Joshua wrote:

I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need
to match whats in ipa idrange-find --all for the AD domain.

# ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0
Range name: TEST.OSUWMC_id_range

Modified ID range TEST.OSUWMC_id_range

Range name: TEST.OSUWMC_id_range
First Posix ID of the range: 10
Number of IDs in the range: 90
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810
Range type: Active Directory domain range


/etc/sssd/sssd.conf:
[domain/test.osuwmc]
ldap_idmap_range_min = 10
ldap_idmap_range_size = 90

There is something completely broken here. You *shouldn't* need to add a
separate domain section for any of the domains coming over the forest
trust link path _at_all_. SSSD automatically derives all needed
parameters for them via its IPA providers for the primary IPA domain.

Jakub, what is going on?








From:  Gould, Joshua Gould joshua.go...@osumc.edu
Date:  Tuesday, March 17, 2015 at 6:08 PM
To:  freeipa-users@redhat.com freeipa-users@redhat.com
Subject:  [Freeipa-users] sssd options ignored?


I¹ve been getting messages like these when I try the id command for a test
AD domain user:

(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_get_primary_name] (0x0400): Processing object farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0400): Processing user farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x1000): Mapping user [farus@test.osuwmc] objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to unix ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0020): Failed to save user [adm-faru03@test.osuwmc]


Various sources all inicate that its a range issue with
ldap_idmap_range_size. I¹ve tried several large values of just
ldap_idmap_range_size as well as adding ldap_idmap_range_min and
ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring
the values? Between changing values I did stop sssd, delete the cache and
restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58.

Here is my full sssd.conf.

[domain/unix.test.osuwmc]
debug_level = 9
subdomains_provider = ipa
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = unix.test.osuwmc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mid-ipa-vp01.unix.test.osuwmc
chpass_provider = ipa
ipa_server = mid-ipa-vp01.unix.test.osuwmc
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_idmap_range_min = 2000
#ldap_idmap_range_size = 90
#ldap_idmap_range_range = 3602000
ldap_idmap_range_size=100
ldap_id_mapping = True

[sssd]
services = nss, sudo, pam, ssh, pac
config_file_version = 2


domains = unix.test.osuwmc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]




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


--
/ 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] sssd options ignored?

2015-03-17 Thread Gould, Joshua
I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need
to match whats in ipa idrange-find --all for the AD domain.

# ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0
Range name: TEST.OSUWMC_id_range

Modified ID range TEST.OSUWMC_id_range

Range name: TEST.OSUWMC_id_range
First Posix ID of the range: 10
Number of IDs in the range: 90
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810
Range type: Active Directory domain range


/etc/sssd/sssd.conf:
[domain/test.osuwmc]
ldap_idmap_range_min = 10
ldap_idmap_range_size = 90





From:  Gould, Joshua Gould joshua.go...@osumc.edu
Date:  Tuesday, March 17, 2015 at 6:08 PM
To:  freeipa-users@redhat.com freeipa-users@redhat.com
Subject:  [Freeipa-users] sssd options ignored?


I¹ve been getting messages like these when I try the id command for a test
AD domain user:

(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_get_primary_name] (0x0400): Processing object farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0400): Processing user farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x1000): Mapping user [farus@test.osuwmc] objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to unix ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0020): Failed to save user [adm-faru03@test.osuwmc]


Various sources all inicate that its a range issue with
ldap_idmap_range_size. I¹ve tried several large values of just
ldap_idmap_range_size as well as adding ldap_idmap_range_min and
ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring
 the values? Between changing values I did stop sssd, delete the cache and
restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58.

Here is my full sssd.conf.

[domain/unix.test.osuwmc]
debug_level = 9
subdomains_provider = ipa
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = unix.test.osuwmc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mid-ipa-vp01.unix.test.osuwmc
chpass_provider = ipa
ipa_server = mid-ipa-vp01.unix.test.osuwmc
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_idmap_range_min = 2000
#ldap_idmap_range_size = 90
#ldap_idmap_range_range = 3602000
ldap_idmap_range_size=100
ldap_id_mapping = True

[sssd]
services = nss, sudo, pam, ssh, pac
config_file_version = 2


domains = unix.test.osuwmc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]




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