I'm writing linux application that integrates with MS Active Directory. For this purpose I'm using Kerberos. I've already implemented mechanism that authenticates domain user with given credentials, but now I want to check if user is member of administrators group.
So I have creds obtained from the function.
error = krb5_get_init_creds_password(context, &creds, principals,
password.c_str(), NULL, NULL, 0, NULL, NULL);
And here I want to implement logic that authorizes user/administrator
if(!error) {
// admin check
}
I'm thinking of using the krb5_verify_init_creds function but I'm not sure how can I do that.
Kerberos does not do authorization, only authentication. (i.e. it can figure out who you are, but not what you are allowed to do).
In general, once you have the kerberos ID, you would ask some authorization service what that ID is allowed to do. In this case, the most straightforward thing to do is to make an ldap query to find out if the user is a member in the group you are interested in.
MS kerberos violates this principle by adding extra group information that AD knows about to the kerberos service tickets. However, I am not aware of any standard kerberos API's that provide access to this information.
As Fred noted, Kerberos is for authentication, not for authorization. While Kerberos ticket issued by an AD DC contains MS-PAC record with additional information about membership of the AD object mapped to this Kerberos principal, you need more than just knowing format of the records presented in the ticket to make use of it.
In a typical Linux environment your application is better to rely on PAM stack to decouple authentication and authorization steps. Typically a PAM session setup is used to run authorization checks. If your Linux machines are configured to use SSSD (either with id_provider = ad or with id_provider=ipa and cross-forest trust between FreeIPA and AD), you can rely on pam_sss to handle both authentication and authorization steps via SSSD.
Recent versions of SSSD support GPO-based access by mapping GPO logon rights to PAM services.
With SSSD your AD users and groups would be presented as POSIX users and groups. This allows you to build a simple access control based on the group membership that you can obtain via getgrouplist(3) call after you mapped Kerberos principal to local user name with krb5_aname_to_localname().
If you still need to know additional information about the user mapped from Kerberos principal, you can utilize infopipe interface of SSSD. The information available through infopipe is gathered from both Kerberos ticket (when available) and AD LDAP (Global Catalog or DC directly). By using infopipe you wouldn't need to resolve SIDs in MS-PAC to names, resolve group membership and verify signatures of the MS-PAC and other components of the ticket as SSSD does it for you. See https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder and http://www.adelton.com/apache/mod_lookup_identity/ for practical implementation.
Related
We are developing an application with an internal user accounts system, but would like to be able to use credentials from Active Directory and/or Windows accounts. To that end we store the User SID in a field in the application's users table. Our login mechanism functions like this:
Prompt user for domain, login, password
Call LogonUser(logon, domain, password, logon_type, logon_provider, &hToken)
If successful, get User SID from hToken
Close hToken
Search our application's database for a user with the given SID; if found, we are considered logged in to that account.
The problem that has come up is this: we have been using LOGON32_LOGON_NETWORK for the logon_type, but we have now run into some security configurations where "Access this computer from the network" is denied, meaning the Network logon type is prohibited.
My question is what logon type should we be using for this situation? Interactive? We are not actually using the Logon token for anything other than extracting the user's SID. Our application has its own internal groups and permissions; we do not use Windows groups or permissions in any way. From the perspective of Windows and the domain controller, all we are doing is logging on and quickly logging off.
Or are we looking at this in a completely wrong way, and we should be using some other login method entirely?
Thanks
I also have been surprised to find out that the LogonUser() with the LOGON32_LOGON_NETWORK type fails when user right "Access this computer from the network" is not granted for Everyone on local computer.
I use the following workaround:
First try LogonUser() with the LOGON32_LOGON_NETWORK type.
If it fails with error ERROR_LOGON_TYPE_NOT_GRANTED, call LogonUser() with the LOGON32_LOGON_NEW_CREDENTIALS type and the LOGON32_PROVIDER_WINNT50 logon provider.
You can communicate with the SSPI services to validate a user's credentials and acquire a token, without requiring special privileges. This requires a lot of obscure code and
See http://support.microsoft.com/kb/180548 for an example; the SSPLogonUser function is where the token is acquired.
The convention is to use LOGON32_LOGON_BATCH, as documented:
This logon type is intended for batch servers, where processes may be executing on behalf of a user without their direct intervention. This type is also for higher performance servers that process many plaintext authentication attempts at a time, such as mail or web servers.
(emphasis mine).
The system administrators may still need to reconfigure the server to grant batch logon access to the users in question, but because this does not grant the user access to any Windows functionality (e.g., the ability to use Remote Desktop, to connect to a network share, or to log on interactively if they somehow gain access to the console) this should not be a problem.
I have been fighting an issue for awhile where I cannot get our application to work with a secondary user store (AD) without specifying the domain name. AD user/role enumeration is working fine, and I am able to login to the WSO2 admin console with an AD account (username only!) granted admin rights via an AD group, so if that works, then I would think the entitlement service would too...
I have determined the reason for this is that while I can login to the application (and WSO2 admin console) with the AD username only, the role assignment is not being picked up by the application unless I specify the domain with the account (domain/user), as confirmed by using the PEP/search tool. If I use the domain/user in PEP search, I can see the entitlements.. if I use the username only, I don't. My XACML is defined to use domain/group for the role. It's worth noting that if I use an internal role with an internal user and applicable XACML policy, the application works perfect.
This looks to be the same bug as for 4.2.0 (https://wso2.org/jira/browse/CARBON-14861) but I cannot find anything similar for 4.5.0. Does anyone know of a way around this other than making my LDAP user store primary?
TIA!
Idea is that, when you are using XACML with multiple user stores feature of Identity Server, you need to send the username with domain name. Therefore, when you are searching, you must set the username to domain/user
I think it is fine, because authorization happened after the authentication. When authenticating, somehow, user's domain name (user store which user has been authenticated) can be known.
The issues that has been referred, is a separate issue.
I have an internal-facing RESTful web service. There are various client applications using the service, and the client apps themselves have end users. The web service needs to authorize requests based on the end user identities.
The question: What are the typical options for authenticating the end user here? That is, I want to authenticate the user, not the client application. (I don't mind if authenticating the client application is part of the scheme, but ultimately I need to know that the end user is who I think he or she is.)
One possible scheme, for example, would be to have per-client system accounts, and then have the client simply assert the user's identity (e.g. in an HTTP request header, say). So we authenticate the client application and delegate user authentication to the client. I don't think this is a very strong scheme, though, because it depends too much on keeping the system account credentials secret. I have seen too many examples of people e-mailing system account credentials around to put much faith in this sort of approach.
Another approach might be to have the client app, upon user login, use the user's credentials to get a token from the API, and then use that token for subsequent API requests. That way the authentication is user-specific without requiring the client app to hang onto the username/password credentials.
Anyway I'd like to have a better sense for the range of options I should be considering here.
The problem that you describe with "delegated authentication" is a real one. It means that a "client application" using it's credentials has access to the whole breadth of user data. This access can be used maliciously (for example a "semi-trusted" app harvesting api data) or negligently (for example an app accidentally exposing a Direct Object Reference Vulnerability - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)
Probably the most prevalent "token based" scheme is OAuth2 (http://oauth.net/2/), and the precursor, OAuth, which many sites choose to continue to use.
OAuth2 has a number of roles:
resource owner (the user in your case)
resource server (your api)
client (the apps you talk about)
authorization server (not clear who or what would fulfil this role in your case)
The basic scheme is that the resource owner authenticates using their credentials directly with the authorization server. They are then asked if they want to grant some information (which may just be a persistent identifier, or a description of the information exposed by your api) to some client. When they accept an 'auth code' is sent to the client and they use that (combined with their own credentials) to receive an 'access token'. This access token can then be used to authenticate against the resource server (which can check it's authenticity back against the authorization server).
Normally the way this is used is that the authorization server and the resource server are owned and managed by the same entity (for example google and facebook would fulfil this role) and then clients are independently managed.
The scheme can also be used internally within an organisation without the "explicit grant" which can still at least confirm that a specific end-user is present before releasing any data from an api.
As far as I understand, oauth2 is the way to go for Google Apps authentication (not openId anymore). However I am still a bit confused about authorization: can you use at the same time 3-legs oauth2 (for contacts, calendar and drive access...) and 2-legs oauth1 (for shared contacts, administration, licensing...)? Or do yo have to use exclusively 2-legs oauth1 (to give full control to domain administrators for example)? Thanks.
You can use Service Accounts in OAuth2 and acess APIs as domain administrator or impersonating a user.
Read more # https://developers.google.com/accounts/docs/OAuth2ServiceAccount
I need to be the service provider in a SAML solution and want to know how the processing of assertions work. I could not find the answer here.
I imagine the assertion would say something like: "I'm John Doe, My ID is: 999"? Do i need an User list that is "in Sync" with the identity provider? Do i need an Access Control list has the same ID's as the SAML Assertions?
Scenario: I have a database with ACL's. I will be the Service Provider while a remote 3rd party system will be the identity provider.
I don't understand how a remote system would know what users i have in my Access Control lists to be able to authorize anyone.
The mapping between user ids at the IdP and users at the SP is not covered by the SAML spec itself. I'd suggest you look at section 5.4, "Establishing and Managing Federated Identities", in SAMLOverview. That should help you determine the most appropriate approach for your scenario.
For the system I work on (which serves as SP for multiple clients/IdPs), we have a mechanism by which clients can associate their own identifiers with users on our system; this mechanism is outside of the SAML implementation. When clients send us SAML assertions, we expect those assertions to identify users using those identifiers (as well as identifying the client themselves using another shared identifier).