Only IPv4 addresses in /var/lib/sss/pubconf/kdcinfo.DOMAIN
by Brian J. Murrell
On my dual-stack network where some machines actually don't have IPv4
connectivity I am finding that whatever is writing IP addresses into
/var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses
and not the KDC's IPv6 addresses.
The result is that such an IPv6 machine cannot reach a KDC until I
remove that file. It ends up being recreated at some subsequent point
again with only the KDC's IPv4 addresses.
Is this a bug or a problem with my configuration?
Cheers,
b.
2 months
Re: SSSD-users: querying GPO list
by Alexey Tikhonov
On Thu, Jun 23, 2022 at 3:19 PM Fisher, Philip <phil.fisher(a)dxc.com> wrote:
> Hello SSSD people
>
> Is there a way to run (on RHEL 8 specifically) a command or query
> information so that a logged in (authorised) user can see the GPOs that are
> active for the session? I have tried Mr. Goggle without success.
>
I don't think there is a suitable command that SSSD provides.
Maybe Samba suit does? I don't know.
SSSD caches downloaded GPOs in `/var/lib/sss/gpo_cache/`, but those aren't
intended for general human consumption.
>
> This information I realise may be obtained from the actual AD server but
> in general this access is not available hence this query.
>
> Thanks.
>
> --
> Phil J Fisher
>
>
> DXC Technology Company -- This message is transmitted to you by or on
> behalf of DXC Technology Company or one of its affiliates. It is intended
> exclusively for the addressee. The substance of this message, along with
> any attachments, may contain proprietary, confidential or privileged
> information or information that is otherwise legally exempt from
> disclosure. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient of this message, you are
> not authorized to read, print, retain, copy or disseminate any part of this
> message. If you have received this message in error, please destroy and
> delete all copies and notify the sender by return e-mail. Regardless of
> content, this e-mail shall not operate to bind DXC Technology Company or
> any of its affiliates to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
1 year, 2 months
AD site discovery with IPA provider
by Orion Poplawski
The docs seem a little unclear to me on this. They note what when using the
AD provider sssd will perform site discovery to find the closest AD
controller. But what about when using the IPA provider? It seems to me like
it doesn't, and if not - why not?
--
Orion Poplawski
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
1 year, 2 months
SSSD-users: querying GPO list
by Fisher, Philip
Hello SSSD people
Is there a way to run (on RHEL 8 specifically) a command or query information so that a logged in (authorised) user can see the GPOs that are active for the session? I have tried Mr. Goggle without success.
This information I realise may be obtained from the actual AD server but in general this access is not available hence this query.
Thanks.
--
Phil J Fisher
DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
1 year, 3 months
SSSD Service cannot start: Someone deleted /etc/sssd/sssd.conf and /etc/krb5.keytab from RHEL 7 server
by Turritopsis Dohrnii Teo En Ming
Subject: SSSD Service cannot start: Someone deleted
/etc/sssd/sssd.conf and /etc/krb5.keytab from RHEL 7 server
Good day from Singapore,
Today 22 Jun 2022 Wednesday, I discovered that someone deleted
/etc/sssd/sssd.conf and /etc/krb5.keytab from one of the Red Hat
Enterprise Linux (RHEL) 7 servers. Hence System Security Services
Daemon (SSSD) cannot start.
I have solved it by copying /etc/sssd/sssd.conf from another RHEL 7
server and generating kerberos keytab file on the Active Directory
Domain Controller Windows Server.
Here is an edited sample of our /etc/sssd/sssd.conf file.
[sssd]
domains = project.domain.com
config_file_version = 2
services = nss, pam
[domain/project.domain.com]
ad_server = addc01.project.domain.com
ad_domain = project.domain.com
krb5_realm = PROJECT.DOMAIN.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u%d
access_provider = ad
The 2 Windows Server commands I used to create a kerberos keytab are:
[1] setspn -A host/rhel7.project.domain.com rhel7
[2] ktpass /princ host/rhel7.project.domain.com(a)PROJECT.DOMAIN.COM
/out rhel7.keytab /crypto All /ptype KRB5_NT_PRINCIPAL -desonly
/mapuser PROJECT\rhel7$ +setupn +rndPass +setpass +answer
After generating rhel7.keytab on the Active Directory Domain
Controller Windows Server, copy the keytab file to the target RHEL 7
server as /etc/krb5.keytab.
As we do not have direct SSH access to the target RHEL 7 server, I
have to copy out rhel7.keytab from the Windows Server using winscp.
Then I use winscp again to upload rhel7.keytab to another intermediate
RHEL 7 server. From the intermediate RHEL 7 server, I used the
following Linux command to transfer rhel7.keytab to the target RHEL 7
server.
$ scp rhel7.keytab user@<IP address of target RHEL 7
server>:/home/user/rhel7.keytab
On the target RHEL 7 server, run the following Linux commands:
$ sudo cp rhel7.keytab /etc/krb5.keytab
Then
$ su -
# systemctl start sssd.service
# systemctl status sssd.service
I have solved the problem!
Reference Guides
================
[1] 22.8.1 Configuring an SSSD Server
Link: https://docs.oracle.com/cd/E37670_01/E41138/html/ch22s08s01.html
[2] How to create a kerberos keytab on Active Directory for Red Hat
Enterprise Linux
Link: https://access.redhat.com/solutions/208173
Regards,
Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
22 Jun 2022 Wednesday
Blogs:
https://tdtemcerts.blogspot.com/
https://tdtemcerts.wordpress.com/
1 year, 3 months
large multirealm AD deployment, slow id $account / ls -l results
by Mark Christian
I'm wondering what configuration options I should be tweaking to
improve id to name resolution when running commands such as ls -l, and
id? My sssd version is 1.16.*, and the sssd configuration consists
of:
[sssd]
domains = DOM1.COM
...
[nss]
entry_cache_timeout=5400
refresh_expired_interval=4050
...
[domain/DOM1.COM]
id_provider = ad
auth_provider = ad
ad_enabled_domains = dom1.com, dom2.com, dom3.com, dom4.com
ldap_referrals = false
ldap_id_mapping = false
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_group_nesting_level = 0
ldap_use_tokengroups = false
...
[domain/DOM1.COM/DOM2.COM]
...
[domain/DOM1.COM/DOM3.COM]
...
[domain/DOM1.COM/DOM4.COM]
...
ldap_user_search_base/ ldap_group_search_base are used to limit which
OUs to query. But at this moment I'm not able to use the filter
option for these parameters to possibly help performance. Some
accounts have as many as 250 groups. enumerating group membership via
"id -G $account" happens quickly enough. Initial name to id mapping is
a bit slow (id $account), but I can tolerate that. I was hoping that
the refresh_expired_interval setting would keep the entry cache from
"losing" the id to name mappings, but it seems that after some period
of time, running something like ls -l on a directory full of hundreds
of different group owned dirs takes longer than I would like.
What sssd.conf options should I be considering to keep the id to name
cache from expiring? What other options or strategies might I
consider to prepopulate the sssd cache? I'm trying to migrate off a
NIS environment, where name to id mapping is near instantaneous and
I'm hoping sssd might perform as well. I'm also investigating
re-architecting AD, placing all groups/accounts in one Domain or
perhaps ditching AD in favor of freeIPA or equivalent. I must
accommodate 50K+ accounts, thousands of groups and ideally get the
same performance that NIS has historically offered.
1 year, 3 months
Re: kvon in keytab is getting out of sync
by Grebe, Sebastian
Hello
It took a while until I was able to get the logs from a failed machine. There have been three occasions been logged where the client updated the AD Password. Both 2022-5-23 and 2022-05-31 have been fine only 2022-06-07 wasn't and locally the kvon was not updated, but on the DC it was. The only difference I can spot this.
Working:
* Found computer account for LC015564$ at: CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Retrieved kvno '16' for computer account in directory: CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Sending NetLogon ping to domain controller: svdc01011.wago.local
* Received NetLogon info from: SVDC01011.wago.local
* Changed computer password
* kvno incremented to 17
* Checking RestrictedKrbHost/lc015564.wago.local
Not working:
* Found computer account for LC015564$ at: CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Retrieved kvno '17' for computer account in directory: CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Sending NetLogon ping to domain controller: svdc03002.wago.local
* Found old kvno '17'
* Changed computer password
* Retrieved kvno '17' for computer account in directory: CN=LC015564,OU=Computer,OU=Minden,OU=Germany,DC=wago,DC=local
* Sending NetLogon ping to domain controller: svdc03002.wago.local
* Received NetLogon info from: SVDC03002.wago.local
* Checking RestrictedKrbHost/lc015564.wago.local
I inclued all log output. To me it looks like the communication is done only in TCP allso I do not see any KRB5KRB_AP_ERR_REPEAT errors. So I believe I have a different problem then Spike.
I do believe that the problem only occurs if the client is connect over VPN. But I have no data to prove this. It may also be related to the side the client is connected to. I have no idea what to check next. Maybe I will set one specific server to be used for updating the computer password.
Mit freundlichen Grüßen / Best regards
WAGO GmbH & Co. KG
Sebastian Grebe
IT Service Center
phone: +49 571 887-9000
fax: +49 571 887-8658
WAGO GmbH & Co. KG
Hansastraße 27
32423 Minden
Deutschland
http://www.wago.com<http://www.wago.com/>
Public
Diese E-Mail einschließlich ihrer Anhänge ist vertraulich und daher allein für den Gebrauch durch den vorgesehenen Empfänger bestimmt. Dritten ist das Lesen, Verteilen oder Weiterleiten dieser E-Mail sowie jedwedes Vertrauen auf deren Inhalt untersagt. Wir bitten, eine fehlgeleitete E-Mail unverzüglich vollständig zu löschen und uns eine Nachricht zukommen zu lassen.
This email may contain material that is confidential and/or privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
WAGO GmbH & Co. KG - Sitz: Minden - Amtsgericht Bad Oeynhausen HRA 6218
Komplementärin: WAGO Beteiligungs GmbH – Sitz: Brunn am Gebirge (Österreich) - Landesgericht Wiener Neustadt, FN 553907w - Niederlassung Minden - Amtsgericht Bad Oeynhausen, HRB 17863
Geschäftsführung: Axel Börner, Kathrin Fricke, Dr. Heiner Lang, Christian Sallach, Jürgen Schäfer, Dr. Karsten Stoll, Yannick Weber
WAGO ist eine eingetragene Marke der WAGO Verwaltungsgesellschaft mbH
1 year, 3 months
sshkey use allows expired account user to access system
by Jim Kinney
Jim Kinney via FreeIPA-users wrote:
It seems if valid ssh keys exist, the expired account status doesn't
block login with ssh keys. Any operation that touches a password is
blocking.
Is there a pam setting in sshd that needs tweaking to deny access if
account is expired?
You may want to cross post this on sssd-users.
rob
--
Computers amplify human error
Super computers are really cool
1 year, 3 months
[SSSD] Announcing SSSD 2.7.1
by Pavel Březina
# SSSD 2.7.1
The SSSD team is proud to announce the release of version 2.7.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.7.1
See the full release notes at:
https://sssd.io/release-notes/sssd-2.7.1.html
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### General information
* SSSD can now handle multi-valued RDNs if a unique name must be
determined with the help of the RDN.
### Important fixes
* A regression in `pam_sss_gss` module causing a failure if `KRB5CCNAME`
environment variable was not set was fixed.
### Packaging changes
* `sssd-ipa` doesn't require `sssd-idp` anymore
### Configuration changes
* New option `implicit_pac_responder` to control if the PAC responder is
started for the IPA and AD providers, default is `true`.
* New option `krb5_check_pac` to control the PAC validation behavior.
* multiple `crl_file` arguments can be used in the
`certificate_verification` option.
1 year, 3 months
