CAS 6.6 How to authenticate user/password with Azure - azure-active-directory

I have been unsuccessful in getting my CAS to use username/password of my Azure AD
Here is a snippet from cas.properties
cas.authn.attribute-repository.azure-active-directory[0].client-id= <id of the app>
cas.authn.attribute-repository.azure-active-directory[0].client-secret=<secret key>
cas.authn.attribute-repository.azure-active-directory[0].tenant= <id>
cas.authn.attribute-repository.azure-active-directory[0].domain=<domaine name>
whenever i try to enter username and password (azure) in cas login i get the message
[Invalid credentials: clientId is null or empty]
Am I missing another setting that's needed in my cas.properties?

Related

while Connecting java webservice to snowflake i am getting error

hostname=jdbc:snowflake://y.ap-south-1.aws.snowflakecomputing.com/
user=
password=
account=y.ap-south-1
database=DEMO_DB
warehouse=COMPUTE_WH
schema=PUBLIC
this is my connection.properties
Every time i got incorrect username or password was specified
The reason for this error is that you are passing the username coming from Azure AD to Snowflake and expecting it to be authenticated with "snowflake" auth mechanism.
In the connection string, pass the following parameter as well:
authenticator=externalbrowser
What this will do is to open a browser session where you can then authenticate the user from AAD and session will pass the auth check.

MSAL Error - Target Principal Name Incorrect with Federated IWA

I have an AAD/AD Federated tenant setup. Obviously AAD in Azure, local AD is lab setup with VMs. I've gone through a few permutations of the AADConnect setup, but I always end up with this same error. Looking it up, it seems usually associated with SQLServer, but I don't think that applies here. I'm simply trying to use IWA to authenticate to this AAD federated app but cannot escape this exception.
Local AD
Domain: vandelay.local
ADDS,ADFS,DNS: WIN-H9QGD6BJ2IN.vandelay.local
ADFS DNS: adfs.ad.vandelay.local
Alternate UPN: vandelay.firstresponse911.net
AAD Connect setup with Federation and Password Hash Sync
AAD
AADConnect setup appears to be happy (see screenshot)
App added with globally granted admin consent for app (does not require user interaction to grant permission)
Users synced with AADConnect appear in portal with permission for App.
Code
// Signed into machine as steve.doe#vandelay.firstresponse911.net
static void Main(string[] args)
{
app = PublicClientApplicationBuilder.Create(CLIENT_ID)
.WithAuthority(AzureCloudInstance.AzurePublic, TENANT_ID, false)
.Build();
while (true)
{
var result = _retry.Execute((ctx) => GetToken2().GetAwaiter().GetResult(), new Context("acquireToken", new Dictionary<string, object>() { { "userId", "paul.seabury#vandelay.local" }, { "password", "AGF11nfn" } }));
Console.WriteLine($"IdTok: {ComputeSha256Hash(result.IdToken)}, Exp: {result.ExpiresOn}");
Thread.Sleep(1000 * 60 * 2);
}
}
private static Task<AuthenticationResult> GetToken2()
{
var upn = System.DirectoryServices.AccountManagement.UserPrincipal.Current;
var cachedResult = app.AcquireTokenByIntegratedWindowsAuth(scopes).WithUsername(upn.UserPrincipalName).ExecuteAsync().GetAwaiter().GetResult();
return Task.FromResult(cachedResult);
}
}
Exception
Microsoft.Identity.Client.MsalClientException: 'The target principal name is incorrect.'
This is accompanied on the same client machine by an EventLog Entry:
The Kerberos client received a
KRB_AP_ERR_MODIFIED error from the server fsgma$. The target name used
was HTTP/win-h9qgd6bj2in.vandelay.local. This indicates that the
target server failed to decrypt the ticket provided by the client.
This can occur when the target server principal name (SPN) is
registered on an account other than the account the target service is
using. Ensure that the target SPN is only registered on the account
used by the server. This error can also happen if the target service
account password is different than what is configured on the Kerberos
Key Distribution Center for that target service. Ensure that the
service on the server and the KDC are both configured to use the same
password. If the server name is not fully qualified, and the target
domain (VANDELAY.LOCAL) is different from the client domain
(VANDELAY.LOCAL), check if there are identically named server accounts
in these two domains, or use the fully-qualified name to identify the
server.
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Security-Kerberos" Guid="{98E6CFCB-EE0A-41E0-A57B-622D4E1B30B1}" EventSourceName="Kerberos" />
<EventID Qualifiers="16384">4</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2020-10-30T15:24:32.660502800Z" />
<EventRecordID>3393</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>DESKTOP-BJ6P4H4.vandelay.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="Server">fsgma$</Data>
<Data Name="TargetRealm">VANDELAY.LOCAL</Data>
<Data Name="Targetname">HTTP/win-h9qgd6bj2in.vandelay.local</Data>
<Data Name="ClientRealm">VANDELAY.LOCAL</Data>
<Binary />
</EventData>
</Event>
Http Traffic
It looks like the MSAL code successfully asks AAD to Authenticate for this app, which via discovery sends the response back to talk to the locally federated ADFS server. After getting the local metadata, the MSAL code attempts 3 times to get a token from the windowstransport endpoint. The first attempt with no Authorization header, the 2nd and 3rd attempt have differing Authorization(Negotiate) headers with encoded data, but they all fail with 401.
The posted request looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
<wsa:messageID>urn:uuid:42420a0c-3505-455f-914d-639c5685b43d</wsa:messageID>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:To s:mustUnderstand="1">https://adfs.ad.vandelay.local/adfs/services/trust/2005/windowstransport</wsa:To>
</s:Header>
<s:Body>
<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsa:EndpointReference>
<wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>
and the sequence looks like this:
It looks like you are using a CNAME in DNS to resolve the adfs farm name -->you should use an Host A Record
Kerberos Clients will first resolve the name of the web service to the A Record before requesting the Kerberos Service Ticket
This would explain the kerberos error you see
"The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server fsgma$. The target name used was HTTP/win-h9qgd6bj2in.vandelay.local. "

Configure Azure AD as Identity provider OIC in Keycloack and email attribute

I success configuring Azure AD as identity provider using OIC in Keycloack. But it ask email during the first connection with keycloak.
And I can't find how to create the mapper to populate email in keycloack with the one of Azure AD.
I figure that it's the userprincipalname that I get the email.
So I try that without success:
The UPN claim is upn. With v2 endpoint of AAD, you could also require the email scope and get the email in email claim. UPN and email can be different in some cases.
I had the same issue.
You need to create a new "Flow" in Authentication tab and "Add Execution" then add the Flow : "Create User If Unique".
In Identity Providers tab, you need to change the "First Login Flow" option, and pick the flow you've just created.

Unable to login via Username/password and Microsoft Graph API, resource owner password credentials, Azure AD

I got error below by following steps below in this example:
Step 1: Clone or download this repository
Step 2: (Optional) Register the sample with your Azure Active Directory tenant
Choose the Azure AD tenant where you want to create your applications
Register the client app (up-console)
Step 3: Configure the sample to use your Azure AD tenant
Run the app:
Enter your username
anyuser#outlook.com
Enter your password (no backspace possible)
*********
Response status code does not indicate success: 406 (NotAcceptable).
Press any key to exit
Enter your username
anyuser#msn.com
Enter your password (no backspace possible)
*********
Response status code does not indicate success: 406 (NotAcceptable).
Press any key to exit
I changed the setting in Supported account types to below, but got the same error
Accounts in any organizational directory and personal Microsoft accounts (e.g. Skype, Xbox, Outlook.com)
Enter your username
anyuser#outlook.com
Enter your password (no backspace possible)
*********
Response status code does not indicate success: 406 (NotAcceptable).
Press any key to exit
Any idea?
anyuser#outlook.com has admin permission
It looks like you may be trying to use a personal Microsoft account. It will not work with this authentication flow.
The password grant (aka resource owner password credentials grant flow) only works with users who are Azure AD users, do not have MFA, and who are not federated. And the password must not have expired.

Unable to lookup idp connection metadata for entityid='http://sp.example.com/sp'

I have service provider application http://sp.example.com/sp and when user accesses it through a browser, user is redirected from my SP application to IdP server which is configured on PingFederate server with an SP connection(http://sp.example.com/sp) as entity id. User is redirected through SAML protocol with SAML AuthnRequest to IdP. But on Ping server I keep getting this error which says
unable to lookup idp connection metadata for entityid='http://sp.example.com/sp'
Does anyone have face similar error before with Ping? This is SP-initiated SSO.
Request I am sending to PingFederate
<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://sp.example.com/sp" Destination="https://idp.com/sp/ACS.saml2" ForceAuthn="false" ID="_93313f7882ff7b3274da46502c4cf072" IsPassive="false" IssueInstant="2014-04-29T15:15:04.666Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Version="2.0"><samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.example.com/sp</samlp:Issuer><saml2p:NameIDPolicy xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AllowCreate="true" SPNameQualifier="https://sp.example.com/sp"/><saml2p:RequestedAuthnContext xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact"><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml2p:RequestedAuthnContext></samlp:AuthnRequest>
You can find possible solutions to your problem in Ping's support center:
https://www.pingidentity.com/support/solutions/index.cfm/SSO-fails-with-Unable-to-lookup-sp-or-idp-connection-metadata-for-entityid
In the server.log, the error "Unable to lookup sp connection metadata
for entityid" is seen. This is usually an indication that there is a
mismatch between the Partner Entity ID (Connection ID) configured in
the IDP-side PingFederate SP Connection and the actual entity ID of
the partner, and therefore PF cannot determine which SP Connection to
use when a SAML AuthnRequest comes in from the SP in the SP-initiated
SSO use case.
https://www.pingidentity.com/support/solutions/index.cfm/Unable-to-lookup-sp-connection-metadata-for-entityid
Since Entity ID is case sensitive, if there is a mismatch between the
value entered for the Partner's Entity ID (Connection ID) field in the
PingFederate Administrative Console and what the partner is sending in
the SAML protocol message, then the SSO attempt will fail with the
"Unable to lookup sp (or idp) connection" error message.
The solution is to verify the Partner's Entity ID (Connection ID)
setting matches exactly what is sent by the partner in the SAML
messages.

Resources