Re: [SSSD-users] Fetching Hosts Entries from OpenLDAP Database

[Michael Ströder]

Simo Sorce wrote:
> On Thu, 2015-08-20 at 10:09 -0400, Stephen Gallagher wrote:
>> On Thu, 2015-08-20 at 00:54 +0200, Michael Ströder wrote:
>>> Dmitri Pal wrote:
 On 08/19/2015 03:53 PM, Jakub Hrozek wrote:
> On Wed, Aug 19, 2015 at 09:49:22PM +0530, Rajnesh Kumar Siwal
> wrote:
>> Any suggested workaround .
> You can use nss-pam-ldapd just for the hosts database and sssd
> for the
> rest, you can use different views or different servers altogether
> for
> public/private views.
>
> btw this is the first time I've heard a request for hosts support
> in
> sssd, so I don't think it's something that can be expected,
> unless
> someone steps in and implements the maps.

 People usually use DNS for that and it is the recommended way of
 doing
 things.
 BTW if you want LDAP managed host entries you can use FreeIPA and
 it comes with DNS to solve this issue.
>>>
>>> But DNS is not subject to access control. Yes, I also already thought
>>> about making host entries visible only to specific hosts.
>>
>> Hmm, access-control is the first good argument I've heard for
>> supporting hosts in LDAP as opposed to DNS[SEC]. Historically, we've
>> ignored the hosts map in SSSD because we reasoned that dnsmasq was a
>> better caching solution for hosts than LDAP. However, being able to
>> restrict what machines have access to the hosts is actually an
>> interesting use-case.
>>
>> If you have a RHEL subscription, I'd encourage you to contact your
>> support representative to make a formal request for inclusion of the
>> hosts map in SSSD. If you do not, please file an RFE at 
>> https://fedorahosted.org/sssd with this justification and upstream will
>> consider it for inclusion in a future release.
> 
> Although a case can be made, it sounds an awful lot like security
> through obscurity ...

I'm not trying to push this as *the* solution.
But it can be another line of defense.

> It may be better to use DNS and ACLS in bind to restrict who (as in IP
> addresses) can see a zone.

YMMV. But imagine a deployment where each host has to strongly authenticate
anyway and is authorized to see only specific users, groups, sudoers entries.
In such a scenario it's not such a big deal to add some OpenLDAP ACLs for
hosts visibility.

In contrast to that implementing bind ACLs is an additional data structure and
authentication can only be done IP-based. Ok, you can sync data to bind of 
course.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Fetching Hosts Entries from OpenLDAP Database

[Simo Sorce]

On Thu, 2015-08-20 at 10:09 -0400, Stephen Gallagher wrote:
> On Thu, 2015-08-20 at 00:54 +0200, Michael Ströder wrote:
> > Dmitri Pal wrote:
> > > On 08/19/2015 03:53 PM, Jakub Hrozek wrote:
> > > > On Wed, Aug 19, 2015 at 09:49:22PM +0530, Rajnesh Kumar Siwal
> > > > wrote:
> > > > > Any suggested workaround .
> > > > You can use nss-pam-ldapd just for the hosts database and sssd
> > > > for the
> > > > rest, you can use different views or different servers altogether
> > > > for
> > > > public/private views.
> > > > 
> > > > btw this is the first time I've heard a request for hosts support
> > > > in
> > > > sssd, so I don't think it's something that can be expected,
> > > > unless
> > > > someone steps in and implements the maps.
> > > 
> > > People usually use DNS for that and it is the recommended way of
> > > doing
> > > things.
> > > BTW if you want LDAP managed host entries you can use FreeIPA and
> > > it
> > > comes with DNS to solve this issue.
> > 
> > But DNS is not subject to access control. Yes, I also already thought
> > about
> > making host entries visible only to specific hosts.
> > 
> 
> 
> Hmm, access-control is the first good argument I've heard for
> supporting hosts in LDAP as opposed to DNS[SEC]. Historically, we've
> ignored the hosts map in SSSD because we reasoned that dnsmasq was a
> better caching solution for hosts than LDAP. However, being able to
> restrict what machines have access to the hosts is actually an
> interesting use-case.
> 
> If you have a RHEL subscription, I'd encourage you to contact your
> support representative to make a formal request for inclusion of the
> hosts map in SSSD. If you do not, please file an RFE at 
> https://fedorahosted.org/sssd with this justification and upstream will
> consider it for inclusion in a future release.

Although a case can be made, it sounds an awful lot like security
through obscurity ...
It may be better to use DNS and ACLS in bind to restrict who (as in IP
addresses) can see a zone.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Public ssh key in AD

[Jakub Hrozek]

quick top-post

I'll be on vacacation starting tomorrow and the whole next week. I hope
some of the other sssd developers can help you out.

tl;dr the public key should be set in ldap_user_ssh_public_key

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

Sorry for being terse.

On Thu, Aug 20, 2015 at 09:29:25PM +0200, Davor Vusir wrote:
> 
> 
> Jakub Hrozek skrev den 2015-08-20 13:20:
> >On Thu, Aug 20, 2015 at 12:40:07PM +0200, Davor Vusir wrote:
> >>Hi!
> >>
> >>We store our public ssh keys in AD user account (altSecurityIdentities).
> >>Red Hat release 6.6/sssd 1.11.6. Adding
> >
> 
> We'll get there in due time.
> 
> ~~~
> >6.7 is out for some time with quite some enhancements.
> >
> >>
> >>subdomains_provider = none
> >>
> >
> >Why would you expect disabling subdomains provider to have any effect on
> >public keys retrieval?
> >
> 
> I don't. I was quite suprised that it does.
> 
> >>alone ends in not being able to get the public key but are asked for our AD
> >>user accounts password.
> >>Adding
> >>
> >>ldap_groups_use_matching_rule_in_chain = True
> >>ldap_initgroups_use_matching_rule_in_chain = True
> >>
> >>makes the logon time so long that it seems that SSSD forgets the content of
> >>the attribute altSecurityIdentities and we are asked for our AD user
> >>accounts password.
> >
> >So why do you add them?
> >
> 
> "This option tells SSSD to take advantage of an Active Directory-specific
> feature which may speed up group lookup operations on deployments with
> complex or deep nested groups.
> 
> In most common cases, it is best to leave this option disabled. It generally
> only provides a performance increase on very complex nestings."
> 
>  - https://jhrozek.fedorapeople.org/sssd/1.11.6/man/sssd-ldap.5.html
> 
> We may not have "very complex nestings", but complex for sure. And
> complexity is growing. My hope was that it would speed up the logon process.
> 
> >In general, neither subdomains_provider nor the matching rules have
> >anything to do with SSH keys whatsoever.
> >
> 
> Thank you for confirming my thoughts. Are there any special cases? We don't
> have any subdomains but many forest trust. These are enumerated and marked
> as subdomains even though SSSD does not support forest trusts. I was hoping
> that disabling this setting would make SSSD neglect the trusted forests.
> According to the logs it seems so.
> 
> >>But logging on immediatly again we are asked for public
> >>key verification.
> >
> >You're asked for verification of /user/ keys?
> >
> 
> We are asked for the password of the public key to unlock the private key.
> 
> >>
> >>Red Hat release 7.1/sssd 1.12.2. . Adding
> >>
> >>subdomains_provider = none
> >>
> >>alone ends in not being able to get the public key but are asked for our AD
> >>user accounts password.
> >>Adding
> >>
> >>ldap_groups_use_matching_rule_in_chain = True
> >>ldap_initgroups_use_matching_rule_in_chain = True
> >>
> >>gives the same result. AD user accounts password only. But not the extended
> >>logon time.
> >>
> >>How come?
> >
> >You didn't paste any logs or configuration, so it's hard to tell. But
> >you should first make sure the backend is configured to point to your
> >pubkey attribute with ldap_user_ssh_public_key, then see if sshd is
> >contacting the ssh responder and if the ssh responder is retrieving the
> >keys from cache.
> >
> 
> Sorry.
> 
> sssd.conf:
> [sssd]
>debug_level = 0 # Levels = 0-9
>config_file_version = 2
>domains = ad.example.org
>services = nss, pac, pam, ssh
> 
> [nss]
>debug_level = 6 # Levels = 0-9
>filter_users = 
> root,bin,daemon,adm,lp,sync,shutdown,halt,mail,uucp,operator,games,gopher,ftp,nobody,dbus,vcsa,abrt,haldaemon,ntp,saslauth,postfix,sshd,tcpdump,puppet
>filter_groups = 
> root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,mail,uucp,man,games,gopher,video,dip,ftp,lock,audio,nobody,users,dbus,utmp,utempter,floppy,vsca,abrt,cdrom,tape,dialout,haldaemon,ntp,saslauth,postdrop,postfix,sshd,tcpdump,stapusr,stapsys,stapdev,slocate,puppet,wbpriv
> # Comment out if the users have the shell and home dir set on the AD side
>allowed_shells = /etc/shells
>default_shell = /bin/bash
>fallback_homedir = /home/%u
> 
> [pac]
>debug_level = 0 # Levels = 0-9
> 
> [pam]
>debug_level = 6 # Levels = 0-9
>offline_credentials_expiration = 0 # For ever
> 
> [ssh]
>debug_level = 9 # Levels = 0-9
> 
> [domain/ad.example.org]
>debug_level = 6 # Levels = 0-9
>id_provider = ad
>auth_provider = ad
>access_provider = ad
>chpass_provider = ad
> 
>subdomains_provider = none
> 
>ldap_page_size = 1000
> 
>enumerate = False
> 
>ldap_id_mapping = False
> 
>ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
>ldap_user_ssh_public_key = altSecurityIdentities
> #   ldap_groups_use_matching_rule_in_c

Re: [SSSD-users] Public ssh key in AD

[Davor Vusir]

Jakub Hrozek skrev den 2015-08-20 13:20:

On Thu, Aug 20, 2015 at 12:40:07PM +0200, Davor Vusir wrote:

Hi!

We store our public ssh keys in AD user account (altSecurityIdentities).
Red Hat release 6.6/sssd 1.11.6. Adding




We'll get there in due time.

~~~

6.7 is out for some time with quite some enhancements.



subdomains_provider = none



Why would you expect disabling subdomains provider to have any effect on
public keys retrieval?



I don't. I was quite suprised that it does.


alone ends in not being able to get the public key but are asked for our AD
user accounts password.
Adding

ldap_groups_use_matching_rule_in_chain = True
ldap_initgroups_use_matching_rule_in_chain = True

makes the logon time so long that it seems that SSSD forgets the content of
the attribute altSecurityIdentities and we are asked for our AD user
accounts password.


So why do you add them?



"This option tells SSSD to take advantage of an Active 
Directory-specific feature which may speed up group lookup operations on 
deployments with complex or deep nested groups.


In most common cases, it is best to leave this option disabled. It 
generally only provides a performance increase on very complex nestings."


 - https://jhrozek.fedorapeople.org/sssd/1.11.6/man/sssd-ldap.5.html

We may not have "very complex nestings", but complex for sure. And 
complexity is growing. My hope was that it would speed up the logon process.



In general, neither subdomains_provider nor the matching rules have
anything to do with SSH keys whatsoever.



Thank you for confirming my thoughts. Are there any special cases? We 
don't have any subdomains but many forest trust. These are enumerated 
and marked as subdomains even though SSSD does not support forest 
trusts. I was hoping that disabling this setting would make SSSD neglect 
the trusted forests. According to the logs it seems so.



But logging on immediatly again we are asked for public
key verification.


You're asked for verification of /user/ keys?



We are asked for the password of the public key to unlock the private key.



Red Hat release 7.1/sssd 1.12.2. . Adding

subdomains_provider = none

alone ends in not being able to get the public key but are asked for our AD
user accounts password.
Adding

ldap_groups_use_matching_rule_in_chain = True
ldap_initgroups_use_matching_rule_in_chain = True

gives the same result. AD user accounts password only. But not the extended
logon time.

How come?


You didn't paste any logs or configuration, so it's hard to tell. But
you should first make sure the backend is configured to point to your
pubkey attribute with ldap_user_ssh_public_key, then see if sshd is
contacting the ssh responder and if the ssh responder is retrieving the
keys from cache.



Sorry.

sssd.conf:
[sssd]
   debug_level = 0 # Levels = 0-9
   config_file_version = 2
   domains = ad.example.org
   services = nss, pac, pam, ssh

[nss]
   debug_level = 6 # Levels = 0-9
   filter_users = 
root,bin,daemon,adm,lp,sync,shutdown,halt,mail,uucp,operator,games,gopher,ftp,nobody,dbus,vcsa,abrt,haldaemon,ntp,saslauth,postfix,sshd,tcpdump,puppet
   filter_groups = 
root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,mail,uucp,man,games,gopher,video,dip,ftp,lock,audio,nobody,users,dbus,utmp,utempter,floppy,vsca,abrt,cdrom,tape,dialout,haldaemon,ntp,saslauth,postdrop,postfix,sshd,tcpdump,stapusr,stapsys,stapdev,slocate,puppet,wbpriv

# Comment out if the users have the shell and home dir set on the AD side
   allowed_shells = /etc/shells
   default_shell = /bin/bash
   fallback_homedir = /home/%u

[pac]
   debug_level = 0 # Levels = 0-9

[pam]
   debug_level = 6 # Levels = 0-9
   offline_credentials_expiration = 0 # For ever

[ssh]
   debug_level = 9 # Levels = 0-9

[domain/ad.example.org]
   debug_level = 6 # Levels = 0-9
   id_provider = ad
   auth_provider = ad
   access_provider = ad
   chpass_provider = ad

   subdomains_provider = none

   ldap_page_size = 1000

   enumerate = False

   ldap_id_mapping = False

   ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
   ldap_user_ssh_public_key = altSecurityIdentities
#   ldap_groups_use_matching_rule_in_chain = True
#   ldap_initgroups_use_matching_rule_in_chain = True
   ldap_use_tokengroups = True

   dyndns_update = False
   dyndns_update_ptr = False

   cache_credentials = true
   krb5_store_password_if_offline = true

Using default settings for subdomains_provider, the key is retrieved:
(Thu Aug 20 20:56:01 2015) [sssd[ssh]] [sss_dp_req_destructor] (0x0400): 
Deleting request: [0x7f78cb8f8490:doma...@ad.example.org]
(Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus 
conn: 0x7f78cd092130
(Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): 
Dispatching.
(Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_message_handler] (0x4000): 
Received SBUS method [ping]
(Thu Aug 20 20:56:11 2015) [sssd[ssh]] [sbus_get_sender_id_send] 
(0x

Re: [SSSD-users] Fetching Hosts Entries from OpenLDAP Database

[Michael Ströder]

Stephen Gallagher wrote:
> If you have a RHEL subscription, I'd encourage you to contact your
> support representative to make a formal request for inclusion of the
> hosts map in SSSD. If you do not, please file an RFE at 
> https://fedorahosted.org/sssd with this justification and upstream will
> consider it for inclusion in a future release.

I don't have a RHEL subscription:
https://fedorahosted.org/sssd/ticket/2766

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Fetching Hosts Entries from OpenLDAP Database

[Stephen Gallagher]

On Thu, 2015-08-20 at 00:54 +0200, Michael Ströder wrote:
> Dmitri Pal wrote:
> > On 08/19/2015 03:53 PM, Jakub Hrozek wrote:
> > > On Wed, Aug 19, 2015 at 09:49:22PM +0530, Rajnesh Kumar Siwal
> > > wrote:
> > > > Any suggested workaround .
> > > You can use nss-pam-ldapd just for the hosts database and sssd
> > > for the
> > > rest, you can use different views or different servers altogether
> > > for
> > > public/private views.
> > > 
> > > btw this is the first time I've heard a request for hosts support
> > > in
> > > sssd, so I don't think it's something that can be expected,
> > > unless
> > > someone steps in and implements the maps.
> > 
> > People usually use DNS for that and it is the recommended way of
> > doing
> > things.
> > BTW if you want LDAP managed host entries you can use FreeIPA and
> > it
> > comes with DNS to solve this issue.
> 
> But DNS is not subject to access control. Yes, I also already thought
> about
> making host entries visible only to specific hosts.
> 


Hmm, access-control is the first good argument I've heard for
supporting hosts in LDAP as opposed to DNS[SEC]. Historically, we've
ignored the hosts map in SSSD because we reasoned that dnsmasq was a
better caching solution for hosts than LDAP. However, being able to
restrict what machines have access to the hosts is actually an
interesting use-case.

If you have a RHEL subscription, I'd encourage you to contact your
support representative to make a formal request for inclusion of the
hosts map in SSSD. If you do not, please file an RFE at 
https://fedorahosted.org/sssd with this justification and upstream will
consider it for inclusion in a future release.

signature.asc
Description: This is a digitally signed message part
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] Public ssh key in AD

[Jakub Hrozek]

On Thu, Aug 20, 2015 at 12:40:07PM +0200, Davor Vusir wrote:
> Hi!
> 
> We store our public ssh keys in AD user account (altSecurityIdentities).
> Red Hat release 6.6/sssd 1.11.6. Adding
  ~~~
6.7 is out for some time with quite some enhancements.

> 
>subdomains_provider = none
> 

Why would you expect disabling subdomains provider to have any effect on
public keys retrieval?

> alone ends in not being able to get the public key but are asked for our AD
> user accounts password.
> Adding
> 
>ldap_groups_use_matching_rule_in_chain = True
>ldap_initgroups_use_matching_rule_in_chain = True
> 
> makes the logon time so long that it seems that SSSD forgets the content of
> the attribute altSecurityIdentities and we are asked for our AD user
> accounts password.

So why do you add them?

In general, neither subdomains_provider nor the matching rules have
anything to do with SSH keys whatsoever.

> But logging on immediatly again we are asked for public
> key verification.

You're asked for verification of /user/ keys?

> 
> Red Hat release 7.1/sssd 1.12.2. . Adding
> 
>subdomains_provider = none
> 
> alone ends in not being able to get the public key but are asked for our AD
> user accounts password.
> Adding
> 
>ldap_groups_use_matching_rule_in_chain = True
>ldap_initgroups_use_matching_rule_in_chain = True
> 
> gives the same result. AD user accounts password only. But not the extended
> logon time.
> 
> How come?

You didn't paste any logs or configuration, so it's hard to tell. But
you should first make sure the backend is configured to point to your
pubkey attribute with ldap_user_ssh_public_key, then see if sshd is
contacting the ssh responder and if the ssh responder is retrieving the
keys from cache.

btw pubkey integration with AD is not something we test, so there might
be dragons..
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] Public ssh key in AD

[Davor Vusir]

Hi!

We store our public ssh keys in AD user account (altSecurityIdentities).
Red Hat release 6.6/sssd 1.11.6. Adding

   subdomains_provider = none

alone ends in not being able to get the public key but are asked for our 
AD user accounts password.

Adding

   ldap_groups_use_matching_rule_in_chain = True
   ldap_initgroups_use_matching_rule_in_chain = True

makes the logon time so long that it seems that SSSD forgets the content 
of the attribute altSecurityIdentities and we are asked for our AD user 
accounts password. But logging on immediatly again we are asked for 
public key verification.


Red Hat release 7.1/sssd 1.12.2. . Adding

   subdomains_provider = none

alone ends in not being able to get the public key but are asked for our 
AD user accounts password.

Adding

   ldap_groups_use_matching_rule_in_chain = True
   ldap_initgroups_use_matching_rule_in_chain = True

gives the same result. AD user accounts password only. But not the 
extended logon time.


How come?

Regards
Davor vusir

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] ad_site syntax

[Ondrej Valousek]

Logs attached to the ticket #2765 I have created for this one.
Ondrej

From: sssd-users-boun...@lists.fedorahosted.org 
[mailto:sssd-users-boun...@lists.fedorahosted.org] On Behalf Of Pavel Reichl
Sent: 20 August 2015 11:48
To: sssd-users@lists.fedorahosted.org
Subject: Re: [SSSD-users] ad_site syntax


On 08/20/2015 11:02 AM, Ondrej Valousek wrote:
Hi folks,

Just testing the ad_site option in sssd.conf – how is this supposed to work? 
Which syntax is it taking? Long DNS path or just site name?
For me, it does not seem to work at all – sssd happily connect to DCs outside 
of the specified site.
Hello, just site name worked for me. Are you sure you are using version where 
this feature is supported? If so, please provide logs.


Ondrej

-



The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s). Please direct any additional queries to: 
communicati...@s3group.com. Thank You. 
Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 
378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.





___

sssd-users mailing list

sssd-users@lists.fedorahosted.org

https://lists.fedorahosted.org/mailman/listinfo/sssd-users


-

The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s). Please direct any additional queries to: 
communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 
Group). Registered in Ireland no. 378073. Registered Office: South County 
Business Park, Leopardstown, Dublin 18.___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Re: [SSSD-users] ad_site syntax

[Pavel Reichl]

On 08/20/2015 11:02 AM, Ondrej Valousek wrote:


Hi folks,

Just testing the ad_site option in sssd.conf – how is this supposed to 
work? Which syntax is it taking? Long DNS path or just site name?


For me, it does not seem to work at all – sssd happily connect to DCs 
outside of the specified site.


Hello, just site name worked for me. Are you sure you are using version 
where this feature is supported? If so, please provide logs.


Ondrej

-

The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s). Please direct any additional queries to: 
communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 
Group). Registered in Ireland no. 378073. Registered Office: South County 
Business Park, Leopardstown, Dublin 18.



___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SSSD-users] ad_site syntax

[Ondrej Valousek]

Hi folks,

Just testing the ad_site option in sssd.conf - how is this supposed to work? 
Which syntax is it taking? Long DNS path or just site name?
For me, it does not seem to work at all - sssd happily connect to DCs outside 
of the specified site.

Ondrej

-

The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s). Please direct any additional queries to: 
communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 
Group). Registered in Ireland no. 378073. Registered Office: South County 
Business Park, Leopardstown, Dublin 18.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users