I understand that the principle of Kerberos is to allow authentication between users and services on an unsecured network. Tickets generated by the authentication and ticket-granting service support secure communications and don't require a password to be transmitted across the network.
The flow relies on the auth server in the KDC (s) having a shared secret with the client (c).
However, at some point, the user itself must have been created and generally, users are created from client machines (you don't usually log onto the domain controller to create users)
So how do the user and secret key (Kac) get created in the first place and stored in the KDC database if the password/secret is never sent across the network?
The administration of principals in a KDC's database is outside the scope of the normal Kerberos protocol. Usually it's done using some auxiliary protocol, and each KDC can implement it in any way it wants.
For example, MIT Kerberos has the (SunRPC-based) kadmin protocol, and the kadmin client indeed sends the actual administrator-specified password to the kadmind service running on the KDC. (The RPC message is encrypted using the Kerberos session key, of course.) Heimdal has its own kadmin protocol, mostly incompatible with MIT's but working the same way.
(Both also have "local" versions of the kadmin tool, which directly accesses the KDC database backend – this is how the initial admin accounts are created, typically by running kadmin.local on the server console or through SSH.)
Microsoft Active Directory has several user administration protocols, some of them dating to pre-AD days, but the primary mechanism is LDAP (usually over an GSSAPI/Kerberos-encrypted session, but occassionally TLS-encrypted).
To create a new account in MS AD, the administrator creates an LDAP 'User' or 'Computer' entry with the plain-text 'userPassword' attribute, and the domain controller automatically transforms this attribute into Kerberos keys (instead of storing it raw). The commonly used "AD Users & Computers" applet (dsa.msc) is really an interface to the LDAP directory.
All of the above implementations also support a second administration protocol, the kpasswd protocol whose sole purpose is to allow an existing user to change their password. As you'd expect, it also works by transmitting the user's new password over the network, again making use of Kerberos authentication and encryption. (Password changes can also be done via AD's LDAP or MIT/Heimdal's kadmin, but kpasswd has the advantage of being supported by all three.)
As a final side note, the PKINIT extension uses X.509 certificates to authenticate the AS-REQ – in which case the client doesn't know their own shared secret, so the KDC in fact sends the whole Kc to the client over the network (encrypted using a session key negotiated via DH, somewhat like TLS would). This is mostly used in Active Directory environments with "smart card" authentication.
Related
I have my snowflake warehouse hosted on an address that looks like this :
*********.snowflakecomputing.com/console (not sure where it is hosted - maybe within the Snowflake cloud). However, I do not have it configured to go through a VPN connection. Is there a way to require that console access is only through VPN?
I think you are asking about Network Policies.
Nit: I am not sure "insecure" is the right word to use. All data is transferred over HTTPS and is therefore encrypted. Using SAML you can use your own authentication provider and use MFA. Thus you can easily match the highest standards of security in the industry.
Yes, you can restrict access to your snowflake account using an account-level network policy.
You can define VPN IP(s) in the allowed IP list in the account level network policy and activate the policy.
After account level activation, everyone is required to connect the VPN before accessing the snowflake account.
Details: https://docs.snowflake.com/en/user-guide/network-policies.html#managing-account-level-network-policies
I have an application that needs to sync periodically to my directory service (OpenLDAP or AD).
To do so, it is necessary to bind an admin account with a DN and password, to access users on LDAP.
As far as I understand, there is the possibility of using anonymous, however for security reasons, its use is not recommended.
Since this periodic synchronization is done automatically by a routine (hourly), I need to store in addition to the account DN, also admin password in the application database.
However, passwords are usually sent to be authenticated in plaintext against
directory service (within a secure SSL / TLS connection) and the directory service itself that finds its password stored in plaintext or some hash (md5, sha-1, etc.)
How to ensure the security of admin password stored in database for synchronization with LDAP? Or, is there a best practice to implement a sync periodic using LDAP?
Applications examples that require password (admin) to read LDAP.
Moodle
(https://docs.moodle.org/37/en/LDAP_authentication#Bind_settings)
Sugar CRM (https://support.sugarcrm.com/Knowledge_Base/Password_Management/Configuring_LDAP_Authentication_Using_Active_Directory/#Prerequisites)
But it does not clear how the password is stored.
It's true that anonymous bind is disabled by default in Active Directory. However, if you are just reading, you don't need an "admin" account. You need any account. The account does not need to have any special permissions. You just need something that can authenticate to the domain.
But if you're going to be authenticating users, then you will need to get the user's password, and you can just use the user's credentials to read from LDAP. That would be true for both AD and OpenLDAP.
I am new to service broker and I am setting up a distributed topology. Two physical servers in the same domain, to replace a hacked up two way replication that continues to cause data corruption.
I am using the same domain account for both ends of the conversation and I am getting "The certificate's private key cannot be found" in profiler.
I had the same setup working with two separate local logins previously, so I am thinking that my issue is the fact that I am now attempting to use the same user account on both ends.
So my question is, does service broker require separate user accounts on each end of the conversation if I am using domain account with windows authentication, and if so is there any real advantage to using domain accounts instead of the way I had it previously with two local logins.
What is the difference/relation between ADAM, Active Directory, LDAP, ADFS, Windows Identity, cardspace and which server (Windows 2003, Windows 2008) uses what?
Active Directory is a server component for administrating windows domains and storing related informations like details about users. It provides implementations of the network protocols LDAP, DNS, CIFS and Kerberos. It's part of Windows Server 2003 as well as Windows Server 2008 with some modifications in the latter case.
ADAM was somewhat like the little brother of Active Directory. It only contained an implementation of LDAP. With Windows Server 2008 it was renamed to LDS, Lightweight Directory Services. ADAM/LDS can also be installed on non-server versions of Windows.
LDAP is a protocol for administrating the data of a directory service. Data within a directory services are stored in a hierarchical manner, a tree. Entries within that tree can contain a set of attributes where each has a name and a value. They are mostly used for storing user related informations like usernames, passwords, email addresses and so on, as there are standardized schemas for this purpose and it's widely supported by applications.
ADFS is a technology which enables Single Sign-On for users of web applications within an Identity Federation. In a very short form: Imagine two organizations which have their user data stored within an active directory. Now each organization wants to give the users of the other organization access to its web applications, but with the restriction that the user data itself should neither be copied nor be fully accessible to the other organization. Thats the kind of problem ADFS can solve. May require an hour of reading & researching before fully understood.
Just to fill in the gaps above:
ADFS is an example of a STS (Security Token Service). STS's can be configured to have a trust relationship with each other. Imagine you have a company which only has internal users and they want to expand to external users. That means that all external users have to register, get a user name, password etc. Perhaps the company doesn't want to store all this stuff. They realise that most of their external users already have an OpenId account. So they federate (trust) their ADFS with an STS that accepts OpenId credentials.
When an external user wants to access the company website, they are asked what kind of user they are via a drop down. They select OpenID. They are then taken to the OpenId site where they authenticate. The user is then redirected back to the company ADFS with a signed token which states that OpenId has authenticated the user. Since there is a trust relationship, the ADFS accepts the authentication and allows the user access to the web site.
None of the OpenId credentials are stored by the company.
Effectively, you have outsourced authentication.
ADFS currently runs on Windows Server 2008 R2.
For Windows Identity (in the context of ADFS) I assume you are asking about Windows Identity Foundation (WIF). This is essentially a set of .NET classes that are added to a project using VS that makes the application "claims aware". There is a VS tool called FedUtil that maps an application to a STS and describes the claims that will be provided. (A claim is an attribute e.g. name, DOB etc.) When a user accesses the application, WIF redirects the user to the mapped STS where the user logs in. WIF then provides the application with a set of claims. Based on these, the application can alter flows based on the user claims. E.g. only users with a claim type of Role with a value of Editor can alter pages.
WIF can also act as an Access Manager E.g. only Editors can access this page. Other users simply receive an error.
In WIF, an application is referred to as a "Relying Party" (RP).
WIF inside VS requires Vista or Windows 7.
Since STS's can be federated with each other, each STS can provide a group of claims.
E.g. in the example above, the OpenId STS can provide the user's name while the company ADFS can provide information not pertinent to OpenId e.g role in the company.
Cardspace is a mechanism to authenticate via a digital identity e.g. an enabled application can ask you to login by selecting one of your "cards", one of which might be e.g. your personal X509 certificate. The application would then check this against the credentials it has stored.
In February 2011, Microsoft announced that they would no longer be developing the Windows CardSpace product.
Typical ISP setup. One server is the web server, another is the DB SQL server. There is a local administrator account, let's say XYZ, created on both machines. So when I log in remotely, I am either WebServer\XYZ or DBServer\XYZ, depending where I log in.
Now, when I login to SQL Server SSMS on DBServer using Windows Authentication, and execute "SELECT SUSER_NAME()", I get DBServer\XYZ. That makes sense since it's picking up the fact that I logged in with those credentials.
Now, move over to the WebServer. I remotely login as WebServer\XYZ. I've installed the SQL client components there. When I launch SSMS, choose the DBServer, login with Windows Authentication, and execute "SELECT SUSER_NAME()", I somehow get DBSERVER\XYZ, instead of what I would assume should be WebServer\XYZ.
Somehow, the XYZ from the WebServer becomes the XYZ from the DBServer. Why is that? How does that happen? Surely, it can't just be because the names happen to be the same?
I've heard of trusted domains, but neither machine is a Domain Controller, so I don't have access to that info. How can I tell if it's trusted or not, without the GUI tools?
The reason I ask the question is because, I'm trying to implement the same thing on my XP laptop (using Virtual PC), so I can imitate the production environment, but I'm not having any luck.
The NTLM challenge between machines is a little more complex #Quassnoi indicates but it is similar. The machines may well be in the same domain or trusted domains, but the accounts you are using are local machine accounts, scoped only to the local machine's security access management.
Local SAM accounts patterned as machinename\userid are non-propagatable. You'd experience a series of negotiated fallbacks when you tried to authenticate against external resources using that account as follows:
Pass current domain/username/password hash token - it'll fail, the account is untrusted
Fallback - revert passing hash of UserID + Password
Fallback - revert to connecting as anonymous credentials.
The fallbacks can also be disabled through configuration, it is very common for anonymous authentication to be prevented.
As #Quassnoi indicates in this instance you managed to login using the #2 fallback.
To enable account credentials to propagate, you'd need the following to be true:
machines would need to be members of domains with at least one-way trust between each other (they don't necessarily have to be members of the same domain).
use domain accounts - not local machine accounts - would look something like domainname\userid. A special case is the Network Service account which has a proxy account in the domain scenario - domainname\machinename$.
How do you tell if your machine is a member of the domain? It's pretty easy if you've got interactive login to the machines. There are a few strategies
interactively the System control panel will show workgroup or domain membership. (Right-click properties on Computer in the start menu)
at the command-line, IPCONFIG /ALL will also show the default DNS prefix which is typically the same as your domain name.
I suspect your ISP would create a domain just to make it easy to manage and monitor their machines. Whether they'd let you create domain accounts is a different question.
You XYZ accounts seem to have same passwords on both machines, and they are not a part of a domain.
WebServer sends just XYZ as a username and answers all password challenges successfuly, as the passwords do match.
DbServer, of course, thinks of you as of DbServer/XYZ, as it knows of no others.
Exactly same thing happens when you try to access one standalone machine from another one over SMB. If your usernames and password match, you succeed.