"a specified logon session does not exist. it may already have been terminated" after i joined the device to azure active directory
-i can't access our shared folder in our server after i joined the device to azure AD and use office 365 account (Please see click the link below to see the error image for your reference), but if i use local administrator of the device i can access the file server using the credentials with no problem, please note that we don't have an premises active directory or GPO, kindly help me.
a specified logon session does not exist. it may already have been terminated
Instead of specifying just "binos" as your username, add hostname with back-slash like so:
yourhostname\binos
In most cases, this will fix that error.
To access the share, the server would also need to be azure ad joined. which you cannot do with windows server, you would need azure ad Domain Services (AD DS) on azure, then join your file server to that.
Only Windows 10 devices can be "azure ad-joined devices"
If you don't want to do that, you could create a azure file store, and secure it using your azure ad / rbac, then map that on your devices.. that would probably work too.
Related
I'm quite new to the Azure AD. So I will be grateful for any hint.
I need to enable members of a given domain (of a given Active Directory) to log in to Azure SQL Server using Azure Active Directory - Integrated Authentication.
So far I've logged into Windows and connected it to Azure Acticve Directory in Windows Setting.
Looking through the documentation, I understand that I need to select one of the authentication methods proposed by Microsoft within Azure Active Directory. The easiest seems to be Password hash synchronization. So I would like to pick this one (But if others are simpliest I am open to change that choice)
What is the easiest way to synchronise this? Can I avoid having to create a Windows Server VM and install Azure AD Connect there?
The current configuration of AD Connect on Azure Portal looks as follows:
To mention it again, the only service I care about is logging in via Azure Active Directory
I apologise if the whole question has been wrongly structured, but it is simply based on what I have found on the forums and in the documentation.
Thanks in advance for any tips
[for example: https://youtu.be/PyeAC85Gm7w?t=565, https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure?tabs=azure-powershell#using-an-azure-ad-identity-to-connect-using-ssms-or-ssdt, https://techcommunity.microsoft.com/t5/azure-sql-blog/azure-ad-pass-through-and-password-hash-authentication-support/ba-p/1269735]
You don't need Azure AD Connect or password hash sync unless you have an on-premise Windows Server AD that you want to sync to Azure AD. Should note that AD is not the same as Azure AD. You don't need Windows Server AD with Azure SQL, just Azure AD. To grant a certain security group access to the server, you can run CREATE USER [group-name-here] FROM EXTERNAL PROVIDER; in the Azure SQL DB. Then you can use standard SQL stuff to grant that "user" access to the DB/tables.
Users should then use Azure Active Directory - Universal with MFA as the authentication method in SQL Server Management Studio.
i have configured kerberos authentication when accessing to file server.
there is no need for logging in when i map drive and acccess to the file server
Just a curious question, if i can add additional server name to be used for authentication
for example.
currently my file server name is server01
when i map network drive through server01 / IP address, there is no issue.
when i tried to access through a server name server02, then i get an error in mapping the drive.
is there any way i can do this by allowing multiple server name to be allowed for kerberos authentication ?
thanks in advance for any advise
You can map as many file shares as possible you want with Kerberos authentication on a Windows domain joined system if the file servers hosting the file shares are joined to the same domain as the client Windows system accessing them.
Thus, you may have multiple file servers in your domain environment but they all should be joined to the AD domain for the Kerberos authentication to work successfully and let the users accessing and mapping the file shares authenticate through it as Kerberos needs a KDC (Key Distribution Center) due to which Active Directory authentication is required.
Please find the below dependencies for Kerberos authentication to work successfully: -
Operating System --> Later then Windows 2000 for client and Windows 2003
TCP/IP Network Connectivity --> Should exist between DC, client, and the target server
Domain System --> DNS must be functioning and accessible for the client
Active Directory Domain --> Necessary to use Kerberos authentication
Time Service --> Time source should be same and synchronized on all the network computers
Service Principal Names --> Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network
Also, refer this document for more details.
I have mounted an azure file share on an azure VM using access keys ,the VM is not doman joined with the azure active directory instance.Please let me know if below scenario's will work out:-
If i apply acl's on the folders and sub folders will the acl's be
enforced in the mounted drive on the VM?
Will AZURE RBAC apply if someone tries to upload a file from the VM?
Note:- The Azure VM is on a VNET which has access to azure active directory.
Any information/answer/suggestion on the above questions would be greatly appreciated.
ACLs can exist for domain or non-domain accounts. Having a machine that is not domain joined, can obviously not set domain ACLs. So in that case local-server ACLs is all you can hope to get.
If another server mounts the share, and there is not another local user account + SID mapping, then there is no way these ACLs have any meaning on the second machine. But they will be enforced.
So that one will work albeit questionable in terms of usefulness.
RBAC is really a management plane construct. Meant to govern who can manage which Azure resource --> not access which data planes. Now in the case of AD / AAD DS support for Azure file shares, the team has decided to "stretch" the meaning of RBAC to govern share-level ACLs via Kerberos (where normal RBAC is OAuth only!)
Enough of the backend: What this basically means, is that there can be no support for local server accounts.
THese accounts only exist on a local server, not in AAD and certainly not DIRSYNC'ed from on-prem AD into AAD. So that means RBAC cannot work for local accounts, only for domain accounts.
I'm unclear what your scenario is.
A user coming into the server with some sort of local user credential?
Then creating/copying a file into a mounted Azure file share to that VM? --> That can work because there is no RBAC and since this is all happening through that single server that has that local user account, ACLs for these local accounts work natively.
A user coming into the server with a domain cred? --> will not work as the server isn't domain joined.
A user coming in with a local-server account and then using the Azure file share not via SMB mount but by going to the Azur file share directly: Cannot work because it's not a domain account and non-dimain accounts cannot work against Azure file shares. You'd use the srtorage access key to mount the file share to the VM, then you have access and leave auth. to the server with the set of local accounts.
Before you enable Azure AD over SMB for Azure file shares, make sure you have completed the following prerequisites:
Select or create an Azure AD tenant.
You can use a new or existing tenant for Azure AD authentication over SMB. The tenant and the file share that you want to access must be associated with the same subscription.
To create a new Azure AD tenant, you can Add an Azure AD tenant and an Azure AD subscription. If you have an existing Azure AD tenant but want to create a new tenant for use with Azure file shares, see Create an Azure Active Directory tenant.
Enable Azure AD Domain Services on the Azure AD tenant.
To support authentication with Azure AD credentials, you must enable Azure AD Domain Services for your Azure AD tenant. If you aren't the administrator of the Azure AD tenant, contact the administrator and follow the step-by-step guidance to Enable Azure Active Directory Domain Services using the Azure portal.
It typically takes about 15 minutes for an Azure AD DS deployment to complete. Verify that the health status of Azure AD DS shows Running, with password hash synchronization enabled, before proceeding to the next step.
Domain-join an Azure VM with Azure AD DS.
To access a file share by using Azure AD credentials from a VM, your VM must be domain-joined to Azure AD DS. For more information about how to domain-join a VM, see Join a Windows Server virtual machine to a managed domain.
Note:Azure AD DS authentication over SMB with Azure file shares is supported only on Azure VMs running on OS versions above Windows 7 or Windows Server 2008 R2.
Select or create an Azure file share.
Select a new or existing file share that's associated with the same subscription as your Azure AD tenant. For information about creating a new file share, see Create a file share in Azure Files. For optimal performance, we recommend that your file share be in the same region as the VM from which you plan to access the share.
Verify Azure Files connectivity by mounting Azure file shares using your storage account key.
To verify that your VM and file share are properly configured, try mounting the file share using your storage account key. For more information, see Mount an Azure file share and access the share in Windows.
I have provisioned a new Amazon Linux server in AWS environment and joined the server to the domain. I can see the Linux machine in the AD but cannot able to login using the AD credentials. However, I have tried to use the AD credentials but the following error has been encountered:
No Supported Authentication Methods Available (Server Sent: Public Key)
Could someone look at this and provide the resolution ?
In Amazon Linux, before you join the server to Active Directory make sure the password authentication attribute is set to true and AllowUsers string is added in /etc/ssh/sshd_config file.
Once added the required parameters, join the server to Active Directory and once joined, you can login directly with your AD credentials
A user is trying to connect to an Azure SQL Database via SQL Server Management Studio (SSMS v16.5.1).
The user's current IP address is not listed in the Azure SQL Server's firewall rules.
Because of this the user is shown the New Firewall Rule dialog.
When the user signs in using their Azure Active Directory (Azure AD) credentials they get an error message saying:
Account has no subscriptions
Clicking "Details" shows:
We experienced issues in connecting to Azure
Additional information:
login account does not have Azure subscriptions.
(Microsoft.SqlServer.Management.ApplicationAuthenticationManagement)
Why is the user getting this error message and how can they add a new firewall rule for their IP address?
Azure support have shared the below with me, based on an Azure documentation article.
Given an Azure SQL Server, only the Active Directory admin or SQL Server admin have permissions to add firewall rules at the server level.
The above error message (somewhat obscurely) indicates that the user is neither.
My personal experience also suggests that Azure AD accounts that are assigned as Subscription Co-administrators can also set firewall rules.
If, and only if, giving the user permissions is appropriate, this can be done by one of three ways:
Specifying the user as the SQL Server admin.
Setting the server's Active Directory admin to be an Azure Active Directory Group and making the user's AD account a member of this group.
Making the user a Co-administrator for the Subscription via https://manage.windowsazure.com/
Be sure to understand the security implications of each option before taking action.
Look at these two tutorials that will be live shortly (later on 1/13/2017):
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-control-access-sql-authentication-get-started
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-control-access-aad-authentication-get-started
These tutorials discuss using server and database level firewall rules with SQL Server authentication and Azure Active Directory authentication.
I hope these help,
Carl
In Azure Portal (https://portal.azure.com/#resource/subscriptions/{Your-GUID}/resourceGroups/AdminPortalDev/providers/Microsoft.Sql/servers/wjidentityserver/databases/{Your-DATABASE_SERVER}/overview )
Select your database
Select "Overview"
"Set server firewall" on the toolbar
Add client IP on the toolbar
Then you will be able to connect from the new IP address.
I was able to add the IP address without being administrator.
The steps in more details are described in https://learn.microsoft.com/en-us/azure/sql-database/sql-database-security-tutorial#create-a-server-level-firewall-rule-in-the-azure-portal.
Other question Client with IP addres is not allowed to access the server Azuredb describes more meaningful message and the same resolution.