[SSSD-users] Re: [Freeipa-users] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

[TomK]

On 3/12/2018 11:25 AM, Rob Crittenden wrote:

TomK wrote:

On 3/7/2018 1:11 PM, Rob Crittenden wrote:
Hey Rob,

When starting idmapd or stopping it, logs on the LDAP server don't
change.  But UID and GID's change to nfsnobody when I set Nobody-User
and Nobody-Group to nfsnobody in /etc/idmapd.conf .


I don't know that merely restarting the service is going to spark
queries against LDAP. You'd probably need to do something to provoke
that (like doing an ls).
Nothing.  Once at restart of the host do I see something from ls but on 
second execution of ls or any type of directory interaction, nothing 
happens.  Then it repeats randomly.



[General]
Verbosity = 9
Domain = nix.my.dom
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
[Static]
[UMICH_SCHEMA]
LDAP_server = idmipa01.nix.my.dom
LDAP_base = cn=accounts,DC=NIX,DC=MY,DC=DOM
LDAP_people_base = DC=NIX,DC=MY,DC=DOM
LDAP_group_base = DC=NIX,DC=MY,DC=DOM


The people basedn should probably be cn=users,cn=accounts,... and the
group base cn=groups,cn=accounts,... Unles it cleverly smashes that
together with LDAP_base, I'm not sure what it does. The 389-ds access
logs will tell you if it is trying at all (note the logs are
write-buffered so you won't see immediate updates).

If you have compat enabled then idmapd may be getting multiple entries,
one from cn=compat and one from the main tree and that could be
confusing it.

No difference.  Even the IP defined users are having this issue.

However, and this may be a very dumb question, but you raised 389-ds 
logs.  I'm using IPA Server, not 389-ds unless you're implying I may 
need packages?  The IPA servers come with 389-ds-base installed but do I 
need this or something else on the IPA clients as well?


In the existing IPA logs, no other log entries corrolate with the 
nfsidmapd messages on the client.


Method = umich_ldap,nsswitch,static
GSS-Methods = umich_ldap,nsswitch,static

However it still lists:

Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: 
user_dn : 
Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: 
passwd  : 
Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: 
use_ssl : no
Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: 
ca_cert : 


and I'm not sure what variables idmapd.conf uses for password and user. 
Still, I've left the LAB KDC open so no users and passes are needed for 
simple lookups.


After setting the above, the messages in the logs changed slightly:

Mar 15 01:29:24 ipaclient01 systemd-logind: New session 5 of user tomk.
Mar 15 01:29:24 ipaclient01 systemd: Started Session 5 of user tomk.
Mar 15 01:29:24 ipaclient01 systemd: Starting Session 5 of user tomk.
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: key: 0x62dd191 type: uid 
value: tomk@localdomain timeout 600
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling 
umich_ldap->name_to_uid
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: ldap_init_and_bind: version 
mismatch between API information and protocol version. Setting protocol 
version to 3
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: 
umich_ldap->name_to_uid returned -2
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling 
nsswitch->name_to_uid
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nss_getpwnam: name 
'tomk@localdomain' domain 'nix.my.dom': resulting localname '(null)'
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nss_getpwnam: name 
'tomk@localdomain' does not map into domain 'nix.my.dom'
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: 
nsswitch->name_to_uid returned -22
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: final 
return value is -22
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling 
umich_ldap->name_to_uid
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: ldap_init_and_bind: version 
mismatch between API information and protocol version. Setting protocol 
version to 3
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: 
umich_ldap->name_to_uid returned -2
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling 
nsswitch->name_to_uid
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nss_getpwnam: name 
'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody'
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: 
nsswitch->name_to_uid returned 0
Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: final 
return value is 0
Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: key: 0x1917bd86 type: gid 
value: tomk@localdomain timeout 600
Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling 
umich_ldap->name_to_gid
Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: ldap_init_and_bind: version 
mismatch between API information and protocol version. Setting protocol 
version to 3
Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: 
umich_ldap->name_to_gid returned -2
Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_

[SSSD-users] Re: Multiple logins by the same user at the same host at nearly the exact time

[Jim Richard]

ok, pretty sure this is selinux related or sssd/pam handling of selinux related

if I put selinux_provider = none

in my sssd.conf

problem goes away AND my slow logins since the latest sssd version for CentOS 
was pushed problem goes away as well

we have 
SELinux status: disabled

everywhere/all hosts

any thoughts?



     
Jim Richard    
    
    

SYSTEM ADMINISTRATOR III
(646) 338-8905  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

> On Mar 13, 2018, at 6:41 AM, Jakub Hrozek  wrote:
> 
> 
> 
>> On 13 Mar 2018, at 04:44, Jim Richard  wrote:
>> 
>> result in:
>> 
>> pam_sss(sshd:account): Access denied for user rundeck: 4 (System error)
>> 
>> I know this has been an issue in the past per some info I see in places like:
>> https://access.redhat.com/solutions/1477473
>> 
>> any chance there's been a regression bringing this issue back?
>> 
> 
> System Error is the default catch-all if SSSD can’t map some internal error 
> onto a more specific error code. A bit like an unhandled exception. You need 
> to enable the debug logs as per 
> https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html and look into 
> the logs what’s going on.
> 
>> 
>>  Jim Richard 
>> SYSTEM ADMINISTRATOR III
>> (646) 338-8905  
>> 
>> 
>> 
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: SSSD and Firewalls

[Galen Johnson]

You can always sniff the network between the client and servers to see
which ports traffic is going over.  Wireshark can do this or your firewall
admin may be able to grab a trace.  It's ugly, but it will tell you every
port used (even ephemeral ones).

=G=

On Wed, Mar 14, 2018 at 4:34 PM, Roger Mårtensson <
roger.martens...@gmail.com> wrote:

> Hi!
>
> Den 2018-03-14 kl. 18:26, skrev Simo Sorce:
>
>> On Wed, 2018-03-14 at 18:01 +0100, Roger Mårtensson wrote:
>>
>>> Hello!
>>>
>>> Got tasked to look at firewall rules and am now wondering if there is a
>>> document anywhere that describes the ports and protocols used by SSSD?
>>>
>>> My list currently consist of: 53 (udp/tcp), 88 (udp), 389 (tcp), 636
>>> (tcp) and 3268 (tcp) and 3269 (tcp)
>>>
>>> If I search on "Windows Client" and ports I get tons of ports and
>>> port-ranges I may need to open. But what do SSSD use?
>>>
>> It really depends on what backend you are using.
>>
>
> Sorry about that. I'm using the AD backend with kerberos (GSSAPI) against
> an Active Directory. (2008R2 at the moment. Hope 2016+ have added more
> ports)
>
> for AD you won't need 636(tcp) but you will need 389 (udp) for site
>> discovery and 445 (tcp) if you use GPOs
>>
>> If you use a plain LDAP server then you won't need 3268/3269
>>
>> For password changes if you use kerberos (including AD) you will need
>> 464(tcp)
>>
> Everything is so much simpler when not using a firewall but then you have
> to deal with the drawbacks.
> Wish there was an popular API that services like this could use to
> announce ports used or propose rules.
>
> If you use one of the pam passwthrough modules you may need othere
>> things (like NIS ports etc... )
>>
>> Simo.
>>
>> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: [Freeipa-users] Auto create NFS home folders on IPA Server.

[Charles Hedrick]

or pam_mkhomedir. Or if using kerberized NFS, our pam_kmkhomedir.

> On Feb 27, 2018, at 3:40 AM, Alexander Bokovoy via FreeIPA-users 
>  wrote:
> 
> On ti, 27 helmi 2018, TomK via FreeIPA-users wrote:
>> On 2/26/2018 1:27 AM, Alexander Bokovoy via FreeIPA-users wrote:
>> Thanks Alex.  + SSSD mailing list.
>> 
>> Two remaining questions.
>> 
>> 1) Creating the NFS user folders on the server itself is not a problem 
>> however I would like to trap events that indicate USER logged into a client 
>> host.  On this event, a home directory could then be created on the FreeIPA 
>> side.  Without such an event I can't precreate it.  So when a user logs into 
>> a client machine, is there any SSSD call initiated to the FreeIPA server 
>> that would show up in a log for example that I could in turn use to run a 
>> small shell script to precreate the user's home folder, if it doesn't exist?
> This is not something FreeIPA can help with. We already have
> pam_oddjob_mkhomedir module and its default configuration provides you a
> way to create directories out of band using oddjob-mkhomedir helper. I
> think at the very least you can have a wrapper that:
> - would check some configuration and push a message to some server to
>  create a home directory somewhere else
> - would wait for a response back that a directory is created (either by
>  polling a home directory appearance or communicating some other way
>  with the remote tool that creates a directory)
> - would otherwise call a standard helper provided by oddjob-mkhomedir
> 
> See /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf for details.
> 
>> 2) Is there a way to get SSSD to retrieve the unixHomeDirectory that's 
>> defined in the UNIX Attribute on the AD side?  Would be handy if I want to 
>> control all home directory locations on the AD side.   The override_homedir 
>> works to force a folder but when I try the %o option to override_homedir, it 
>> appears to take the FreeIPA default home directory, not the AD one.
> unixHomeDirectory is the default for ldap_user_home_directory for AD
> provider. Since all IPA trusted subdomains are using AD provider,
> unixHomeDirectory would just be used automatically.
> 
>> 
>> Cheers,
>> Tom
>> 
>>> On su, 25 helmi 2018, TomK via FreeIPA-users wrote:
 Hey Guy's,
 
 For newly added AD or IPA users, is there a way to automatically create 
 the user folders on the FreeIPA server under say /nfs/home/bill, for 
 example so that when the remote client logs in, it sees the NFS mounted 
 folder?
 
 Instructions that I can find right now require precreating the folders. 
 Need them precreated via the FreeIPA master servers anytime someone 
 attempts to login on a client using their AD credentials.  Is this 
 possible?  Assume the NFS server will be local to the FreeIPA masters.
>>> One needs to create home directories on the NFS server itself. If home
>>> directories are mounted via NFS, then you need to have enough permission
>>> to create the folder at the NFS root which is not what you'd want to
>>> allow a regular user. Thus, it needs to be solved outside of a log-in
>>> flow.
>>> 
>>> We don't provide any means to solve this in FreeIPA because file
>>> sharing/hosting is not a FreeIPA problem. If your NFS server is running
>>> on an IPA master, though, you might want to consider not using NFS
>>> mounts on that server itself. In this case a normal oddjob-based
>>> pam_mkhomedir would create the directories just fine.
>>> 
 
 Found steps like the one below but step 5) still requires pre creation of 
 the folders.
 
 https://www.redhat.com/archives/freeipa-users/2016-May/msg00380.html
 
 https://serverfault.com/questions/705039/how-to-automate-directory-creation-on-nfs-server
 
 
 -- 
 Cheers,
 Tom K.
 -
 
 
 Living on earth is expensive, but it includes a free trip around the sun.
 ___
 FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
 To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>>> 
>> 
>> 
>> -- 
>> Cheers,
>> Tom K.
>> -
>> 
>> Living on earth is expensive, but it includes a free trip around the sun.
>> ___
>> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
> -- 
> / Alexander Bokovoy
> ___
> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an ema

[SSSD-users] Re: SSSD and Firewalls

[Roger Mårtensson]

Hi!

Den 2018-03-14 kl. 18:26, skrev Simo Sorce:

On Wed, 2018-03-14 at 18:01 +0100, Roger Mårtensson wrote:

Hello!

Got tasked to look at firewall rules and am now wondering if there is a
document anywhere that describes the ports and protocols used by SSSD?

My list currently consist of: 53 (udp/tcp), 88 (udp), 389 (tcp), 636
(tcp) and 3268 (tcp) and 3269 (tcp)

If I search on "Windows Client" and ports I get tons of ports and
port-ranges I may need to open. But what do SSSD use?

It really depends on what backend you are using.


Sorry about that. I'm using the AD backend with kerberos (GSSAPI) 
against an Active Directory. (2008R2 at the moment. Hope 2016+ have 
added more ports)



for AD you won't need 636(tcp) but you will need 389 (udp) for site
discovery and 445 (tcp) if you use GPOs

If you use a plain LDAP server then you won't need 3268/3269

For password changes if you use kerberos (including AD) you will need
464(tcp)
Everything is so much simpler when not using a firewall but then you 
have to deal with the drawbacks.
Wish there was an popular API that services like this could use to 
announce ports used or propose rules.



If you use one of the pam passwthrough modules you may need othere
things (like NIS ports etc... )

Simo.


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Experiencing a bug on users' name and ID

[Asif Iqbal]

On Tue, Mar 13, 2018 at 3:24 AM, Sumit Bose  wrote:

> On Mon, Mar 12, 2018 at 03:05:43PM -0400, Asif Iqbal wrote:
> > On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal  wrote:
> >
> > >
> > >
> > > On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose  wrote:
> > >
> > >> On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
> > >> > I still like some help with any workaround in dealing with string.
> > >> >
> > >> > IT LDAP team do not have any attribute value with real number. Is it
> > >> > possible to create a local DB to map the mnetid to a real number and
> > >> then
> > >> > use that table as a reference for ID mapping? I am not sure if this
> > >> > discussion should be in developer mailing list.
> > >>
> > >> You might want to try local overrides, see man sss_override for
> details.
> > >>
> > >
> > > Let me read up on it real quick and explore that. What should I be
> looking
> > > for?
> > > How to override mnetid attribute value type from string to integer?
> > >
> > >
> >
> > So I see 5% of current users have mnetid with leading 0.
> >
> > So I never used sss_override. How do I use sss_override to make mnetid
> > 004311
> > to work with sss when ldap id mapping tries to map 4311 instead?
> >
> > Appreciate your help!
>
> I haven't tested it with your setup but
>
> sss_override user_add mwvande --uid 4311 --gid 4311
> sss_override group_add mwvande --gid 4311
>
> should create the needed override data so that user and group mwvande
> can be looked up with the ID 4311.
>


So I can lookup by 4311 after this. Very nice!

Do I need to restart sssd after these two commands?



>
> HTH
>
> bye,
> Sumit
>
> >
> >
> >
> >
> > >
> > >
> > >> As an alternative you might want to try to enable enumeration. After
> the
> > >> initial enumeration run is done all users and groups are already in
> > >> SSSD's cache and lookups by id should work. But I'm not sure if
> > >> enumeration can handle you setup where user and groups are defined by
> > >> the same LDAP object.
> > >>
> > >>
> > > During initial setup, before this server was in production, I tried
> > > enumeration on
> > > and I think login were failing and it was doing ldap query for 2500
> users
> > > and
> > > almost was not responding. So kind of risky to go that path, since most
> > > users'
> > > mnetd id do not have leading `0' and I might add more problem than
> > > solution :-)
> > >
> > >
> > >
> > >> Finally, if it is possible to remove the leading '0's from mnetid it
> > >> should work as well because then '(mnetid=4311)' would match as string
> > >> as well.
> > >>
> > >>
> > > I think I have the worst IT  LDAP team. They will not change there
> schema
> > > and
> > > remove any leading 0s from mnetid.
> > >
> > > Might be little off-topic, but I am not sure if we could have a ldap
> sync
> > > all attributes
> > > to a local ldap server minus the mnetid and we populate that with
> numbers.
> > > Probably
> > > also add more work to address few user accounts with leading 0s
> > >
> > >
> > > bye,
> > >> Sumit
> > >>
> > >> >
> > >> > Appreciate any help
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Mar 8, 2018 11:29 PM, "Asif Iqbal"  wrote:
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek 
> > >> wrote:
> > >> >
> > >> > > I think the next good step would be to show the LDIF and logs of a
> > >> > > resolution of a single faulty entry, e.g. 80974 which you used
> > >> earlier as
> > >> > > an example of an entry that doesn’t work.
> > >> > >
> > >> >
> > >> > Here are some logs for this account
> > >> >
> > >> > dn: uid=mwvande,ou=People,dc=mnet,dc=qintra,dc=com
> > >> > mnetid: 004311
> > >> >
> > >> > (Thu Mar  8 22:10:22 2018) [sssd[be[LDAP]]]
> > >> [dp_get_account_info_handler]
> > >> > (0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4311]
> > >> > (Thu Mar  8 22:10:22 2018) [sssd[be[LDAP]]]
> [sdap_get_generic_ext_step]
> > >> > (0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectclass=
> > >> > mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0][ou=People,dc=
> > >> > mnet,dc=qintra,dc=com].
> > >> > (Thu Mar  8 22:10:22 2018) [sssd[be[LDAP]]]
> [dp_table_value_destructor]
> > >> > (0x0400): Removing [0:1:0x0001:1::LDAP:idnumber=4311] from reply
> table
> > >> > (Thu Mar  8 22:10:29 2018) [sssd[be[LDAP]]]
> > >> [dp_get_account_info_handler]
> > >> > (0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311]
> > >> > (Thu Mar  8 22:10:29 2018) [sssd[be[LDAP]]]
> [sdap_get_generic_ext_step]
> > >> > (0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass=
> > >> > inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0][ou=
> > >> > People,dc=mnet,dc=qintra,dc=com].
> > >> > (Thu Mar  8 22:10:29 2018) [sssd[be[LDAP]]]
> [dp_table_value_destructor]
> > >> > (0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply
> table
> > >> > (Thu Mar  8 22:11:14 2018) [sssd[be[LDAP]]]
> > >> [dp_get_account_info_handler]
> > >> > (0x0200): Got request for [0x1][BE_REQ_USER][name=4311@

[SSSD-users] Re: Multiple logins by the same user at the same host at nearly the exact time

[Jim Richard]

Thanks.

I deployed a clean/new Fedora 27 minimal, installed ipa-client/sssd, we have 
sssd version 1.16.0-6.fc27 on that virtual machine now, and then enrolled the 
host in our FreeIPA.

Then I did a:
service sssd stop ; rm -rvf /var/lib/sss/db/* ; rm -rvf /var/lib/sss/mc/* ; rm 
-rvf /var/log/sssd/* ; service sssd start

added log level 9 to all sections of the sssd config file

Ran my test and then tar'd up the sssd log files and attached them here.
I did look them over beforehand but I'm not seeing anything interesting that I 
would recognize other than:

(Wed Mar 14 14:50:06 2018) [sssd[pam]] [pam_dp_process_reply] (0x0200): 
received: [4 (System error)][placeiq.net ]

A little more background. 

Of course we don't run Fedora in production, it's all CentOS, mostly 7 and some 
6. And we use FreeIPA.

We use Rundeck (http://rundeck.org/ ) for job scheduling 
and we have a few jobs that can, if not properly scheduled, trigger multiple 
logins to the same host, by the same FreeIPA user, at the same time.

This did not used to cause problems but unfortunately Puppet pushed out an 
update to sssd to all of our CentOS nodes last Friday, March 9 and with this 
updated sssd version we started seeing failures.


     
Jim Richard    
    
    

SYSTEM ADMINISTRATOR III
(646) 338-8905  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

> On Mar 13, 2018, at 6:41 AM, Jakub Hrozek  wrote:
> 
> 
> 
>> On 13 Mar 2018, at 04:44, Jim Richard  wrote:
>> 
>> result in:
>> 
>> pam_sss(sshd:account): Access denied for user rundeck: 4 (System error)
>> 
>> I know this has been an issue in the past per some info I see in places like:
>> https://access.redhat.com/solutions/1477473
>> 
>> any chance there's been a regression bringing this issue back?
>> 
> 
> System Error is the default catch-all if SSSD can’t map some internal error 
> onto a more specific error code. A bit like an unhandled exception. You need 
> to enable the debug logs as per 
> https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html and look into 
> the logs what’s going on.
> 
>> 
>>  Jim Richard 
>> SYSTEM ADMINISTRATOR III
>> (646) 338-8905  
>> 
>> 
>> 
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: SSSD and Firewalls

[Simo Sorce]

On Wed, 2018-03-14 at 18:01 +0100, Roger Mårtensson wrote:
> Hello!
> 
> Got tasked to look at firewall rules and am now wondering if there is a 
> document anywhere that describes the ports and protocols used by SSSD?
> 
> My list currently consist of: 53 (udp/tcp), 88 (udp), 389 (tcp), 636 
> (tcp) and 3268 (tcp) and 3269 (tcp)
> 
> If I search on "Windows Client" and ports I get tons of ports and 
> port-ranges I may need to open. But what do SSSD use?

It really depends on what backend you are using.
for AD you won't need 636(tcp) but you will need 389 (udp) for site
discovery and 445 (tcp) if you use GPOs

If you use a plain LDAP server then you won't need 3268/3269

For password changes if you use kerberos (including AD) you will need
464(tcp)

If you use one of the pam passwthrough modules you may need othere
things (like NIS ports etc... )

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: SSSD and Firewalls

[Lukas Slebodnik]

On (14/03/18 18:01), Roger Mårtensson wrote:
>Hello!
>
>Got tasked to look at firewall rules and am now wondering if there is a
>document anywhere that describes the ports and protocols used by SSSD?
>
>My list currently consist of: 53 (udp/tcp), 88 (udp), 389 (tcp), 636 (tcp)
>and 3268 (tcp) and 3269 (tcp)
>
ldaps(636) needn't be allowed if you use ldap+start_tls or ldap+gssapi

You might allow also 88(tcp) for kerberos // not just udp
+ also 464 for kpasswd

>If I search on "Windows Client" and ports I get tons of ports and port-ranges
>I may need to open. But what do SSSD use?
>

If you use sssd with AD + GPO for access control then you might need to allow
access remote ports for samba. I assume following one based on SElinux policy

sh# semanage port -l | grep ^smbd_port_t
smbd_port_ttcp  445, 137-139

LS
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] SSSD and Firewalls

[Roger Mårtensson]

Hello!

Got tasked to look at firewall rules and am now wondering if there is a 
document anywhere that describes the ports and protocols used by SSSD?


My list currently consist of: 53 (udp/tcp), 88 (udp), 389 (tcp), 636 
(tcp) and 3268 (tcp) and 3269 (tcp)


If I search on "Windows Client" and ports I get tons of ports and 
port-ranges I may need to open. But what do SSSD use?


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] SSSD strangeness

[simonc99]

Hi All

We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.

We've used realmd to join the host concerned to our 2008R2 AD system. This went 
really well, and consequently we've been using SSSD to provide login services 
and kerberos integration for our fairly large hadoop system.

The authconfig that's implicitly run as part of realmd produces the following 
sssd.conf:

[sssd]
domains = 
config_file_version = 2
services = nss, pam

[pam]
debug_level = 0x0080

[nss]
timeout = 20
force_timeout = 600
debug_level = 0x0080

[domain/]
ad_domain = 
krb5_realm = 
realmd_tags = manages-system joined-with-samba
cache_credentials = true
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = 
krb5_use_kdc_info = False
entry_cache_timeout = 300
debug_level = 0x0080
ad_server = 

As I've said - this works really well. We did have some stability issues 
initially, but they've been fixed by defining the 'ad_server' rather than using 
autodiscovery.

Logins work fine, kerberos TGTs are issued on login, and password changes are 
honoured correctly.

However, in general day to day use, we have noticed a few anomalies, that we 
just can't track down.  

Firstly (this has happened a few times), a user will change their AD password 
(via a Windows PC). 

Subsequent logins - sometimes with specific client software - fail with

pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh 
ruser= rhost= user=
pam_sss(sshd:auth): received for user : 17 (failure setting user 
credentials)

So in this example, the person concerned has changed their AD password. Further 
attempts to access this system via SSH work fine. However, using SFTP doesn't 
work (the above is output into /var/log/secure).

There are no local controls on sftp logins, and the user concerned was working 
fine (using both sftp and ssh) until they updated their password.

There is no separate sftp daemon running, and it only affects one individual 
currently (but we have seen some very similar instances before)

The second issue we have is around phantom groups in AD.

Hadoop uses an id -Gn command to see group membership for authorisation.

With some users - we've seen 6 currently - we see certain groups failing to be 
looked up:

id -Gn 

id: cannot find name for group ID y


The y indicates:

 = hashed realm name
y = RID from group in AD

We can't find any group with that number on the AD side!

We can work around this by adding a local group (into /etc/group) for the GIDs 
affected. This means the id -Gn runs correctly, and the hadoop namenode can 
function correctly - but this is a workaround and we'd like to get to the 
bottom of the issue.

Rather than flooding this post now with logfiles, just thought I'd see if this 
looked familiar to anyone. Happy to upload any logs, amend logging levels, etc.

Many thanks
Simon
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: [Freeipa-users] Re: Re: Auto create NFS home folders on IPA Server.

[Charles Hedrick]

I noted before that we have a Kerberized mkhomedir. There’s a pam module, 
pam_kmkhomedir. It does a kerberized call to a service on the NFS server or 
some other system that has the file system mounted in a way that it can create 
directories. We did this because we use Kerberized NFS. Root can’t create home 
directories if NFS is kerberized. However presumably a daemon on the NFS server 
can. Since we use a Netapp, we had to do a non-Kerberos export to a secure 
service host, and run the daemon there. But normally I’d expect the daemon to 
run on the NFS server itself.

> On Mar 4, 2018, at 11:49 AM, TomK via FreeIPA-users 
>  wrote:
> 
> On 3/4/2018 10:23 AM, Galen Johnson wrote:
> Hey Galen / Trevor,
> 
> Thanks for replying.  Like other posters seem to be having, sssd / oddjobd / 
> mkhomedir isn't even trying to make a directory on /n which is an automounted 
> NFSv4 path:
> 
> [root@ipaclient01 oddjobd.conf.d]# grep -Ei mkhomedir /etc/pam.d/*
> /etc/pam.d/fingerprint-auth:session optional pam_oddjob_mkhomedir.so 
> umask=0077
> /etc/pam.d/fingerprint-auth-ac:session optional pam_oddjob_mkhomedir.so 
> umask=0077
> /etc/pam.d/password-auth:session optional pam_oddjob_mkhomedir.so 
> umask=0077
> /etc/pam.d/password-auth-ac:session optional pam_oddjob_mkhomedir.so 
> umask=0077
> /etc/pam.d/smartcard-auth:session optional pam_oddjob_mkhomedir.so 
> umask=0077
> /etc/pam.d/smartcard-auth-ac:session optional pam_oddjob_mkhomedir.so 
> umask=0077
> /etc/pam.d/system-auth:session optional  pam_oddjob_mkhomedir.so 
> umask=0077
> /etc/pam.d/system-auth-ac:session optional pam_oddjob_mkhomedir.so 
> umask=0077
> [root@ipaclient01 oddjobd.conf.d]#
> 
> 
> I have no_root_squash enabled temporarily as I test everything out (It's only 
> a LAB) and I can make the folder as root from within the client (ie by typing 
> the command in myself) but it just doesn't work from within oddjobd / 
> mkhomedir for some reason unless it's on a local UNIX filesystem.  It appears 
> only able to change directory to an NFS v4 mount, not actually create 
> anything on it.
> 
> What I'm trying to do is follow an earlier suggestion and send the directory 
> creation over to the NFS v4 Cluster I have by setting up a client-server type 
> of python code.  The code opens up a port on the NFSv4 server and accepts a 
> set of messages.  Then the client send the server a message and waits for a 
> reply, then the client logs the user in once directory is created and 
> available.  I've succeeded so far as to get oddjobd to run my custom code and 
> send 'something' over to the server but I can't get oddjobd to give up the 
> user it's trying to create the directory for.
> 
> To be perfectly open, I'm not yet convinced having this TCP/IP client-server 
> code would be much better then no_root_squash but optimistic that via python, 
> I can provide better security in the long run, if not the short run.
> 
> Seems this might be related to the first problem above.  Maybe I'm not 
> getting a user via oddjobd.conf because the NFSv4 mount isn't recognized?  
> (This is a guess and I'm really stretching here.)
> 
> -- 
> Cheers,
> Tom K.
> -
> 
> Living on earth is expensive, but it includes a free trip around the sun.
> 
> 
> Not to loose Trevor's reply, I'm including it here.
> ---
> On 3/4/2018 11:21 AM, Trevor Vaughan via FreeIPA-users wrote:
> > I use this in a cron job that's dropped by Puppet.
> >
> > https://github.com/simp/pupmod-simp-simp_nfs/blob/master/templates/etc/cron.hourly/create_home_directories.rb.erb
> >
> > https://github.com/simp/pupmod-simp-simp_nfs/blob/master/manifests/create_home_dirs.pp
> >
> > There's really no way to do this in real time without a LOT of
> > additional infrastructure since you're looking at rapid cross-system
> > based on enterprise-wide log processing. Users can generally wait the
> > <=60 minutes that a cron job will entail.
> >
> > Trevor
> 
> 
> 
> 
>> This is most likely due to the nfs mount having 'root_squash" set which 
>> prevents remote servers root from from writing as root (typically nobody or 
>> nfsnobody).  If you are confident that the servers are secure, you could 
>> mount the NFS share with 'no_root_squash'.  It has some security concerns 
>> but it would allow oddjob_mkhomedir to create homedirs.  Another option 
>> would be to add '' in addition to root.
>> =G=
>> On Sun, Mar 4, 2018 at 3:53 AM, TomK > > wrote:
>>On 2/28/2018 11:19 PM, TomK wrote:
>>On 2/27/2018 3:40 AM, Alexander Bokovoy wrote:
>>On ti, 27 helmi 2018, TomK via FreeIPA-users wrote:
>>On 2/26/2018 1:27 AM, Alexander Bokovoy via
>>FreeIPA-users wrote:
>>Thanks Alex.  + SSSD mailing list.
>>Two remaining qu