CIFS insufficient access error when "enterprise admin" AD account is used to establish 1-way trust
by Chris Dagdigian
Dealing with outsourced IT organization that manages an AD domain we are
tying to build an additional trust with so we can upgrade and replace
our fleet of IDM servers.
We got a webex work session going with a domain admin to build the trust
but we keep seeing this on the CLI and WebUI:
ipa: ERROR: Insufficient access: CIFS server XXXXXX.COMPANY.COM denied
your credentials
Running in debug or verbose mode does not reveal more error details and
I can't find much in the logs on the IPA server
The AD admin we were working with claims he used an account that is part
of the Enterprise Admin group and thus should be allowed to do "all the
things" -- they are asking for any docs or details we have on what
permissions the IPA server needs when trust building
Looking for info/tips on the following, thanks!
1) Any log locations or places where I can find more info about why the
ad-trust setup failed?
2) Any docs or listing of specific AD permissions needed by the AD admin
account used to establish the trust
AD is not my strong point - apologies if this is a dumb query!
Regards,
Chris
5 years, 10 months
More on ldap_idmap_range
by Craig H Silva (Cenitex)
As it happens my paranoia seems to be on message.
We have just deployed 4 new sles 12 systems, with the following config:
id_provider = ad
auth_provider = ad
subdomains_provider = none
access_provider = ad
enumerate = false
cache_credentials = true
These systems were deployed without ldap_idmap_default_domain_sid or ldap_idmap_default_domain.
And the range they have started using is different to the range that exists on other deployed systems.
It appears that sssd has returned a different range from that which exists on our other systems.
I would apreciate advice on how to configure a range that will be uniform from the start.
Thanks for your help in advance.
Craig Silva
_________
Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM
Cenitex | Level 15, 80 Collins Street, Melbourne 3000
ph: 03-8688-1297 mob: 0429 365 609 | www.cenitex.vic.gov.au<http://www.cenitex.vic.gov.au/>
This office is located on the land of the Traditional Owners of the Kulin Nation.
[cenitex logo]<http://www.cenitex.vic.gov.au/> [cid:image004.jpg@01D36DDE.27450B80] <https://www.facebook.com/CenITex.vic.gov.au/> [cid:image006.jpg@01D36DDE.27450B80] <https://twitter.com/cenitex> [cid:image010.jpg@01D36DDE.27450B80] <https://www.linkedin.com/company/314749/>
Accountability, Collaboration, Respect, Initiative and Courage
----------------------------------------------------------------------
Notice:
This email and any attachments may contain information that is personal,
confidential, legally privileged and/or copyright. No part of it should be
reproduced, adapted or communicated without the prior written consent of the
copyright owner.
It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return
email, delete it from your system and destroy any copies. You are not authorised
to use, communicate or rely on the information contained in this email.
Please consider the environment before printing this email.
5 years, 10 months
ldap_idmap_default_domain_sid & ldap_idmap_range_size advice requested
by Craig H Silva (Cenitex)
As mentioned in a previous post, I work in an environment with a large AD tree with in excess of 30000 groups and multiple subdomains.
We authenticate against the primary domain and are using ldap_id_mapping after having migrated from using posix attributes (the admin overhead was becoming prohibitive)
Recently we were experimenting with using the ldap_idmap_default_domain_sid as a measure to ensure that the allocated uids and gids were protected against arbitrary change as new domains were encountered in the environment.
We had not specified it previously and it did not have any deleterious effect until we attempted to purge a group that was affecting an update of the database (see previous message on Re: apparent error with ad_enum_cross_dom_members). sss_cache -E wouldn't purge this group so I deleted the databases and config in /var/lib/sss/db and restarted sssd with the effect that sssd started using a different range - not good.
Unfortunately this only increased my paranoia.
At this point I'm not sure as to how to proceed to ensure that the current range is maintained as inclusion of ldap_idmap_default_domain_sid will start the use of a new range.
I also experimented with increasing the ldap_idmap_range_size from the default of 200000 to test whether the issue was due to encountering rids beyond the default range but this also triggered sssd to use a new range.
Basically I'm getting into territory beyond the scope of my experience and seek advice on either biting the bullet and accepting a change in the range and specifying the default sid and dealing with the change on client systems, or getting advice on how to configure sssd to lock on the range its currently using without changing it.
Relevant config in sssd.conf :
id_provider = ad
auth_provider = ad
access_provider = ad
subdomains_provider = none
enumerate = true
ignore_group_members = true
cache_credentials = true
ldap_id_mapping = true
ldap_schema = ad
# ldap_idmap_default_domain_sid = S-1-5-21-3009471437-2678356326-1117381816
ldap_idmap_default_domain = our domain.com
# ldap_idmap_range_size = 500000
Thanks in advance
Craig Silva
_________
Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM
Cenitex | Level 15, 80 Collins Street, Melbourne 3000
ph: 03-8688-1297 mob: 0429 365 609 | www.cenitex.vic.gov.au<http://www.cenitex.vic.gov.au/>
This office is located on the land of the Traditional Owners of the Kulin Nation.
[cenitex logo]<http://www.cenitex.vic.gov.au/> [cid:image004.jpg@01D36DDE.27450B80] <https://www.facebook.com/CenITex.vic.gov.au/> [cid:image006.jpg@01D36DDE.27450B80] <https://twitter.com/cenitex> [cid:image010.jpg@01D36DDE.27450B80] <https://www.linkedin.com/company/314749/>
Accountability, Collaboration, Respect, Initiative and Courage
----------------------------------------------------------------------
Notice:
This email and any attachments may contain information that is personal,
confidential, legally privileged and/or copyright. No part of it should be
reproduced, adapted or communicated without the prior written consent of the
copyright owner.
It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return
email, delete it from your system and destroy any copies. You are not authorised
to use, communicate or rely on the information contained in this email.
Please consider the environment before printing this email.
5 years, 10 months
apparent error with ad_enum_cross_dom_members
by Craig H Silva (Cenitex)
Background - stupidly large AD domain with 30,000 plus groups. It is a forest with a number of legacy domains that are not relevant to our authentication on Linux but the AD admins don't want to allow us to mess with their schema so we still use group membership to manage sudo.
We're also attempting to align with Windows through use of nested groups to fit in with enterprise preference for RBAC.
It's complicated and there's no resourcing to put in place an IPA service which would help.
Anyway these are the relevant config elements:
id_provider = ad
auth_provider = ad
access_provider = ad
subdomains_provider = none
enumerate = true
ignore_group_members = true
cache_credentials = true
ldap_id_mapping = true
ldap_schema = ad
( I can provide full config if requested). We had gone to full enumeration and ignore_group_members to ensure that the groups that provide sudo access are available without ridiculous cpu utilisation and it was working but hit this apparent issue:
[sssd[be[ourdomain.xxx.xxx]]] [ad_enum_cross_dom_members] (0x0080): Failed to add [CN=RG-Ourcompany-Ops-3rd Party-Data\#3-G,OU=CenITex,OU=Operations Roles,OU=Delegated Groups,OU=
Infrastructure Security,DC=ourcompany,DC=xxx,DC=xxx,,DC=xx]: Input/output error
Can raise a bug report if it's clear that this is the issue.
Symptom is that group enumeration that was comprehensive, now seems to stop abruptly.
Cheers
Craig Silva
_________
Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM
Cenitex | Level 15, 80 Collins Street, Melbourne 3000
ph: 03-8688-1297 mob: 0429 365 609 | www.cenitex.vic.gov.au<http://www.cenitex.vic.gov.au/>
This office is located on the land of the Traditional Owners of the Kulin Nation.
[cenitex logo]<http://www.cenitex.vic.gov.au/> [cid:image004.jpg@01D36DDE.27450B80] <https://www.facebook.com/CenITex.vic.gov.au/> [cid:image006.jpg@01D36DDE.27450B80] <https://twitter.com/cenitex> [cid:image010.jpg@01D36DDE.27450B80] <https://www.linkedin.com/company/314749/>
Accountability, Collaboration, Respect, Initiative and Courage
----------------------------------------------------------------------
Notice:
This email and any attachments may contain information that is personal,
confidential, legally privileged and/or copyright. No part of it should be
reproduced, adapted or communicated without the prior written consent of the
copyright owner.
It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return
email, delete it from your system and destroy any copies. You are not authorised
to use, communicate or rely on the information contained in this email.
Please consider the environment before printing this email.
5 years, 10 months
2FA integration: FreeIPA and Mac OS
by Oleksandr Yermolenko
Hi,
Has someone managed to setup OTP 2FA between FreeIPA 4.5.X and Mac
OS (High Sierra)?
When authenticating with a non 2FA user, works fine.
THE FIRST WAY: native heimdal client:
aae$ kinit --version
kinit (Heimdal 1.5.1apple1)
Copyright 1995-2011 Kungliga Tekniska Högskolan
Send bug-reports to heimdal-bugs(a)h5l.org
aae$
aae$ kdestroy
aae$ kinit --anonymous
aae$ klist
Credentials cache: KCM:74E6A71B-BCB9-43E1-8832-AFC7B17831E7
Principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
Issued Expires Principal
Jun 20 12:41:07 2018 Jun 21 12:41:06 2018 krbtgt/IDM.CRP(a)IDM.CRP
aae$ kinit
--fast-armor-cache=KCM:74E6A71B-BCB9-43E1-8832-AFC7B17831E7
aae(a)IDM.CRP
kinit: krb5_init_creds_set_fast_ccache: Matching credential
(krbtgt/WELLKNOWN:ANONYMOUS@WELLKNOWN:ANONYMOUS) not found
aae$
Found [1] that FAST is supported but is it enough for OTP I have
no idea. Tried tcp protocol [2] without success. I can't find
information how to activate anon FAST on Mac OS if this protocol
is supported. What about OTP? I'm not sure that old heimdal
kerberos client is compatible with pkinit/fast. I know so many
questions to apple developers and support
---------------------------------------------
THE SECOND WAY: client MIT version krb5-1.16.1
port install kerberos5
...
---> Installing kerberos5 @1.16.1_0
...
slightly changed /etc/krb5.conf
aae$ kdestroy
kdestroy: No credentials cache found while destroying cache
aae$ kinit -n
aae$ klist -A
Ticket cache: KCM:501
Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
Valid starting Expires Service principal
06/20/2018 12:46:22 06/21/2018 12:46:22 krbtgt/IDM.CRP(a)IDM.CRP
aae$ kinit -T KCM:501 aae(a)IDM.CRP
Enter OTP Token Value:
aae$
aae$ klist -A
Ticket cache: KCM:501:2
Default principal: aae(a)IDM.CRP
Valid starting Expires Service principal
06/20/2018 12:47:13 06/21/2018 12:46:59 krbtgt/IDM.CRP(a)IDM.CRP
Ticket cache: KCM:501
Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
Valid starting Expires Service principal
06/20/2018 12:46:22 06/21/2018 12:46:22 krbtgt/IDM.CRP(a)IDM.CRP
aae$
much much better, but it's not enough because I can't use TGT. As
you can see I tried to use KCM cache believing that I use native
heimdal KCM server on my Mac, but without success: I do not see
any valid tickets here /System/Library/CoreServices/<Ticket
Viewer> and of course don't have kerberos related access to
corporate resources.
----------------------------------------------
Any help is appreciated. Possible directions/ideas how to
implement 2FA on Mac OS without hacks?
I have successfully setup linux using pam-krb5 and anon_fast
option.
References:
[1]
https://www.redhat.com/archives/freeipa-users/2016-December/msg00214.html
[2]
https://www.redhat.com/archives/freeipa-users/2016-December/msg00219.html
--
Oleksandr Yermolenko
systems engineer
5 years, 10 months
SSH public keys and cache invalidation
by Bart
Hi all,
I have set up ipa server, established trust with an ad controller and enrolled a couple of clients to it.
I have a problem understanding how to properly set up ssh pubkey authentication when it comes to caching.
The issue is that when I upload the key to the server (via the web ui, for an AD user) and later delete this key (also via the web UI) I still can log in on a client machine for a couple of days using my private ssh key part. The command sss_ssh_authorizedkeys ad_user shows the correct key on both server and a client. Even after I delete manually cache files on the client, then sss_ssh_authorizedkeys displays the correct key.
In a trial and error process of debugging it I added entry_cache_user_timeout = 60 to every section of sssd.conf on a client but it did not change much the situation described above.
I assume that this is due to the caching settings on the server side (I guess user entries are still present in the sssd cache yet they are not visible in the web ui).
Can someone please point me to the sssd cache settings that would cause ssh keys to stop from working within a reasonable time after they were deleted?
Below I paste sanitized sssd config for the server:
[domain/ipa.domain/ad.domain]
debug_level = 10
# Enable short names without full domain
use_fully_qualified_names = False
ad_server = ad-1.ad.domain,ad-2.ad.domain
#cache_first = True
[domain/ipa.domain]
ad_server = ad-1.ad.domain,ad-2.ad.domain
debug_level = 10
id_provider = ipa
ipa_server_mode = True
ipa_server = ipa-server.ipa.domain
ipa_domain = ipa.domain
ipa_hostname = ipa-server.ipa.domain
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True
enumerate = False
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
ignore_group_members = True
ldap_purge_cache_timeout = 0
#cache_first = True
[sssd]
debug_level = 10
domain_resolution_order = ad.domain, ipa.domain
services = nss, pam, ifp, ssh, sudo
domains = ipa.domain
[nss]
debug_level = 10
filter_users = root,fedora
homedir_substring = /home
memcache_timeout = 600
entry_negative_timeout = 3600
override_shell = /bin/bash
override_homedir = /home/%u
homedir_substring = /home
[pam]
debug_level = 10
[sudo]
debug_level = 10
[autofs]
debug_level = 10
[ssh]
debug_level = 10
[pac]
debug_level = 10
[ifp]
debug_level = 10
[secrets]
debug_level = 10
[session_recording]
debug_level = 10
and the client:
[domain/ipa.domain/ad.domain]
entry_cache_user_timeout = 60
debug_level = 10
# Enable short names without full domain
use_fully_qualified_names = False
subdomain_homedir = /home/%u
selinux_provider = none
ad_enable_gc = false
ad_server = ad-1.ad.domain,ad-2.ad.domain
[domain/ipa.domain]
entry_cache_user_timeout = 60
debug_level = 9
ad_enable_gc = false
subdomain_homedir = /home/%u
# Optimization
selinux_provider = none
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
ignore_group_members = True
cache_first = True
ldap_purge_cache_timeout = 0
ldap_sudo_smart_refresh_interval = 60
ldap_sudo_full_refresh_interval = 21600
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.domain
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = ipa-client.ipa.domain
chpass_provider = ipa
ipa_server = _srv_, ipa-server.ipa.domain
dns_discovery_domain = ipa.domain
[sssd]
entry_cache_user_timeout = 60
domain_resolution_order = ad.domain,ipa.domain
services = nss, sudo, pam, ssh
domains = ipa.domain
entry_cache_user_timeout = 60
[nss]
entry_cache_user_timeout = 60
override_shell = /bin/bash
override_homedir = /home/%u
filter_users = root,fedora
homedir_substring = /home
[pam]
entry_cache_user_timeout = 60
debug_level = 9
[sudo]
entry_cache_user_timeout = 60
debug_level = 9
[autofs]
[ssh]
entry_cache_user_timeout = 60
debug_level = 9
[pac]
debug_level = 9
[ifp]
debug_level = 9
5 years, 10 months
auth to pther providers still using freeipa
by Andrew Meyer
My company is wanting to use FreeIPA for everything. However we also utilize other external services that have their own auth system but can support oauth, or gsuite/facebook etc etc. Is this possible w/ FreeIPA?
Also,Searching through google I found this - Ipsilon. Would you recommend I use that?
|
| |
Ipsilon
By Ipsilon Project Ipsilon identity provider project homepage | |
|
Thank you!
5 years, 10 months
Can't uninstall client
by Bret Wortman
I'm trying to uninstall and reinstall the ipa client on a particular
system. Here's what it looks like:
# ipa-client-install --uninstall -U
# ipa-client-install --enable-dns-updates --mkhomedir
IPA client is already configured on this system.
If you want to reinstall the IPA client, uninstall it first using
'ipa-client-install --uninstall'.
The ipa-client-isntall command failed. See
/var/log/ipaclient-install.log for more information
# ipa-client-install --uninstall -U
#
Repeat at will.
I've not encountered a client this "sticky" before. Any suggestions for
busting it loose so I can get this system working again? It's currently
enrolled with a set of IPA servers that have been decommissioned. I even
tried powering one back on but that didn't help.
--
photo
*Bret Wortman*
Founder, Damascus Products, LLC
855-644-2783 <tel:855-644-2783> | bret(a)wrapbuddies.co
<mailto:bret@wrapbuddies.co>
http://wrapbuddies.co/
10332 Main St Suite 319 Fairfax, VA 22030
<http://facebook.com/wrapbuddiesco>
<http://www.linkedin.com/in/bretwortman>
<http://twitter.com/wrapbuddiesco>
<http://instagram.com/wrapbuddies>
5 years, 10 months
