Edit

Share via

Set-CsAuthConfig

  • Reference
Module:
SkypeForBusiness
Applies to:
Skype for Business Server 2015, Skype for Business Server 2019

Use the Set-CsAuthConfig cmdlet to modify the authentication configuration for your organization.

Syntax

Set-CsAuthConfig
   [-Scenario] <AuthConfigScenario>
   [[-Pool] <String>]
   [-WhatIf]
   [-Confirm]
   [<CommonParameters>]

Description

Use the Set-CsAuthConfig cmdlet to modify the authentication configuration for your organization. The 5 supported scenarios are described in the following list. Scenario is a required parameter. All other parameters are optional. MA is Modern Authentication and Win is Windows Integrated Authentication in the following list.

  • Scenario 1: External: MA + Win; Internal: MA + Win; Parameter: AllowAllExternallyAndInternally. This is the default scenario when MA is turned on for Skype for Business Server. In other words, this is the starting point when MA is configured.

  • Scenario 2: External: MA; Internal: MA + Win; Parameter: BlockWindowsAuthExternally. This topology blocks NTLM externally, but allows NTLM or Kerberos (for clients that don't support ADAL) to work internally. If your clients do support ADAL they will use MA internally.

  • Scenario 3: External: MA; Internal: MA; Parameter: BlockWindowsAuthExternallyAndInternally. This topology requires MA for all users. All your ADAL-capable clients will work in this topology, and passwords will not be leveraged if, for example, you turn off the use of passwords with Certificate-based Auth.

  • Scenario 4: External: MA; Internal: Win; Parameter: BlockWindowsAuthExternallyAndModernAuthInternally. This topology blocks NTLM externally and MA internally. It allows all clients to use legacy authentication methods internally (even ADAL-capable clients).

  • Scenario 5: External: MA + Win; Internal: Win; Parameter: BlockModernAuthInternally. Externally, your modern ADAL clients will use MA and any clients that don't support ADAL will use legacy authentication methods. But, internally all clients will use legacy authentication (including all ADAL-capable clients).

This cmdlet sets configuration on both the Registrar and the Web Services roles.

It is only meant to be run at the global level (and not at the pool level), and we highly recommend that you only use it in this manner. However, technically it can be run at a pool level. But realize that if the pool only has one of the roles needed (say, Registrar and not Web Services), then only the settings for Registrar will be set and the Web Services settings will come from the global setting. No special warning will be given because some settings were not set. If a client uses the Registrar settings from one pool and the Web Services settings from another pool and the authentication settings are in an inconsistent state, the client may be unable to log on. If neither role is present for a pool, Get will return an error message. If both roles are present for a pool but policies aren't defined at the pool level, Get will return an error message.

Examples

Example 1

PS C:\> Set-CsAuthConfig -Scenario BlockWindowsAuthExternally

This example forces all external clients to use MA but allows NTLM or Kerberos (for clients that don't support ADAL) to work internally. If your clients do support ADAL they will use MA internally.

Example 2

PS C:\> Set-CsAuthConfig -Scenario BlockWindowsAuthExternalyAndModernAuthInternally

This example blocks NTLM externally and MA internally. It forces all external clients to use MA, but allows all clients to use legacy authentication methods internally (even ADAL-capable clients).

Note

Please note that in the current version of the module the parameter value BlockWindowsAuthExternalyAndModernAuthInternally is misspelled and to be able to use it, only one l for Externally should be used.

Parameters

-Confirm

Prompts you for confirmation before running the cmdlet.

Type:SwitchParameter
Aliases:cf
Position:Named
Default value:None
Required:False
Accept pipeline input:False
Accept wildcard characters:False
Applies to:Skype for Business Server 2019

-Pool

{{Fill Pool Description}}

Type:String
Position:0
Default value:None
Required:False
Accept pipeline input:True
Accept wildcard characters:False
Applies to:Skype for Business Server 2019

-Scenario

{{Fill Scenario Description}}

Type:AuthConfigScenario
Accepted values:Custom, AllowAllExternallyAndInternally, BlockWindowsAuthExternally, BlockWindowsAuthExternallyAndInternally, BlockWindowsAuthExternalyAndModernAuthInternally, BlockModernAuthInternally
Position:1
Default value:None
Required:True
Accept pipeline input:True
Accept wildcard characters:False
Applies to:Skype for Business Server 2019

-WhatIf

Shows what would happen if the cmdlet runs. The cmdlet is not run.

Type:SwitchParameter
Aliases:wi
Position:Named
Default value:None
Required:False
Accept pipeline input:False
Accept wildcard characters:False
Applies to:Skype for Business Server 2019

Inputs

Microsoft.Rtc.Management.Authentication.AuthConfigScenario

System.String

Outputs

System.Object

Notes

After changing CsAuthConfig, you must run Enable-CsComputer on each Skype for Business Server machine before your changes take effect.