#StackBounty: #sql-server #azure-sql-database #active-directory #azure Service Principal as SQL Active Directory Admin, does it use Gra…

Bounty: 100

I’m looking to use a service principal as the server admin, so it can be used in a release pipeline to create further active directory users.

I’m successfully able to make the service principal the server admin* and connect to the database using an Access token, so the service principal authentication works fine, which is great nice and an interesting challenge.

*EDIT: The AAD server admin was creating via the ARM template, notably if you tried creating manually via the portal, you cannot select service principals as admin users. But interestingly you can see the service principal name ok in the portal after creation using ARM instead. And you can login successfully with AAD auth, so it appears a server principal admin works fine.

However when creating further users, they never seem to be found with the error:

“Principal ‘name here’ could not be found at this time. Please try again later.”

However when logged in as myself I am able to create other users fine.

Which leads me to think is SQL Server using some sort of Active Directory impersonation to validate the subsequent users / service principals exist?

If I were to grant my service principal access to the Graph API would that give it enough permissions? If so what is the minimum rights necessary?

I also see that Azure SQL Server has created a managed service identity in the background, so I wonder if that’s also at play?

Also I saw on managed instances that they explicitly require a service principal with AAD rights to hook into AAD – which I presume is like an Azure SQL Server’s MSI? But Azure SQL Server doesn’t mention this with an AAD admin being enough.

I’d love to know how the underlying mechanism for the active directory hookup works as it could help me investigate my challenges further.


Get this bounty!!!

#StackBounty: #active-directory #redhat #kerberos Kerberos authentication to root domain in Active Directory

Bounty: 50

I have an environment in Active Directory that is composed of a root and a child domain, let’s call them my.root.domain.com and root.domain.com

I have a RHEL7 server I’ve spun up which has no problem at all authenticating against the “my.root.domain.com” domain. I cannot, however, authenticate using an account in the “root.domain.com” domain. I can look up accounts using id in both domains:

id -a user1@my.root.domain.com

and

id -a user2@root.domain.com

both show my AD groups. As the root user, I can even “su – ” to any user in either domain (doesn’t require authentication). The problem arises when authentication happens. Trying to authenticate to user2@root.comain.com fails.

in smb.conf I have:

...
workgroup = MY
realm = MY.ROOT.DOMAIN.COM
security = ads
...

in /etc/krb5.conf I have:

[libdefaults]
dns_lookup_realm = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
proxiable = true
rdns = false
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = MY.ROOT.DOMAIN.COM
dns_lookup_kdc = true
[realms]
MY.ROOT.DOMAIN.COM = {
}
ROOT.DOMAIN.COM = {
}

[domain_realm]
my.root.domain.com = MY.ROOT.DOMAIN.COM
.my.root.domain.com = MY.ROOT.DOMAIN.COM
root.domain.com = ROOT.DOMAIN.COM
.root.domain.com = ROOT.DOMAIN.COM

A packet trace does reveal that when trying to authenticate as user2@root.domain.com, it sends a KRB query of:

CNameString: ROOT.DOMAIN.COMuser2
realm: MY.ROOT.DOMIAN.COM

I know I’m the village idiot when it comes to the AD stuff, but hoping someone has a good suggestion. I’m fairly certain my krb config is not quite what it should be.

Does anyone have any suggestions to utilize accounts from the domain “root.domain.com” domain to authenticate against?


Get this bounty!!!