Authentication Issues

Current Setup:
Windows 2003 Server
SQL Server 2000 w/ SP3
Windows Sharepoint Servics

Problem:
I have created a group on our Domain (INT) called Domain Users. Inside this group I have added individual users that need to be there.

On the SQL Server when I try to add INT\Domain Users I get an error stateing that the user does not exist. Next I tried typing in INT and selecting the browse button. The window opens up listing all Domain users and groups including the one I added 'Domain Users'. I select Domain users from the Drop down list and hit OK. I then hit OK at the bottom of the Add User window and get the error User does not exist.

Any help or insight would be greatly appreciated.

Thank You
Tom McClung

Can you execute the following statement in Query Analyzer and post the output here:

sp_grantlogin 'INT\Domain Users'

Please post both the line containing the error number and error state, and the line containing the error message.

Thanks
Laurentiu

|||Server: Msg 15401, Level 11, State 1, Procedure sp_grantlogin, Line 41
Windows NT User or Group 'INT\Domain Users' not found. Check the name again.

Tom
|||Just a bit more information incase it's needed.

This server is not the domain controller. The domain controller is running Windows 2k Server software.

Tom
|||

Thanks for the information.

I have two additional questions:

(1) Are you able to add any INT user as a SQL login, or do you hit the same error for any INT principal that you attempt to add with sp_grantlogin.

(2) What was the tool that you were using to browse the domain users, which you mentioned in the initial email?

Not sure if it is related, but have you considered upgrading to SP4?

Thanks
Laurentiu

|||(1) The only one that was added was INT\Administrator. Every other INT account delivers the same error using sp_grantlogin.

(2) In the SQL server enterprise manager I went to the security folder and then clicked on logins. Then groups. In the group window at the top I typed in INT and clicked the browse button next to it. This brought up a drop down menu of all the INT users and groups correctly.

(3) I will download SP4 and test.

Tom
|||SP4 installed and I still have the same authentication issues.

I can see the INT domain users in the SQL Server Login menu but when I attempt to add the error comes up with user does not exist.

Tom
|||

What is the service account that SQL Server is running under? One possibility might be that the service account cannot query the INT domain. Did you add the Administrator account manually?

You could also attempt to install SQL Server Express and perform the same operation (as a precaution, you should backup your existing databases to avoid any loss). The error messages in SQL Server 2005 provide additional information that could help identify the issue. Make sure you set SQL Server Express to run under the same account as the existing SQL Server 2000 installation.

Thanks
Laurentiu

|||This is likely to be unrelated to SQL Server; check DNS is properly configured otherwise comms with DCs will be problematic - use ping, nslookup and arp commands to verify this.

Also, adding domain groups into local groups on the server, through compmgmt.msc > Local Users and Groups will deterimne if everythings okay at the OS level.

If that is working, it could be that the SQL Service is lacking in user rights, or the account you are interactively logged in with is either local or otherwise unable to enumerate accounts on the domain.|||Make sure u got checked mix authentication mode on ur server.|||

I am having exactly the same problem.

Setup:

SQL Server 2000 Standard Edition SP4; service login account is a domain account that is a member of domain admins (it was not for normal operation; I added it to domain admins to see if login creation would work - it did not)

Windows 2003 Server Standard Edition, SP1 and all subsequent updates installed; it is an AD domain controller in a single-domain forest.

I am logging onto the DC with a domain admin username/password

DCs are replicating fine; I created a test group on one DC and saw it immediately on other DC. For this issue, tried creating a new group on first one DC, then the other (non-SQL Server) one.

As with the initial post, I can see all groups and users - incl. my newly created group - in the security pulldown, but selecting my group fails exactly as initial post specifies. I.e. I am not typing anything (so no typos), just picking from pre-populated lists.

Mixed authentication is enabled. Tried rebooting after creating AD group; still failed. Tried adding SQL Server to AD; still failed. Error message 15401 is unhelpful, nor does MS site have any further helpful info.

Infrastructure works fine; this is a small LAN, everything resolves etc.

The SQL Server has been operational for a month or so. *Nothing* else has been installed on this DC.

We do have some group policy settings in place; very minimal though. Does anyone know if anything in routine group policy could possibly prevent a domain admin logged into Windows 2003 from adding a login for a domain group when the SQL Server service is running under a (separate) domain admin account?

Any help is appreciated. Thanks.

UPDATE: I was able to add my domain group to the BUILTIN Administrators group using AD Users and Computers. The same domain group cannot be added in SQL Server as described above.

Mulhall wrote:

This is likely to be unrelated to SQL Server; check DNS is properly configured otherwise comms with DCs will be problematic - use ping, nslookup and arp commands to verify this.
Also, adding domain groups into local groups on the server, through compmgmt.msc > Local Users and Groups will deterimne if everythings okay at the OS level.
If that is working, it could be that the SQL Service is lacking in user rights, or the account you are interactively logged in with is either local or otherwise unable to enumerate accounts on the domain.

|||

The authentication mode does not matter for the operation of creating a login.

Just to make sure I understand this setup: is SQL Server 2000 installed on the DC machine, or on a different machine?

Thanks
Laurentiu

|||

OK, I figured out how to at least fix the symptom temporarily. Maybe someone more expert than me at AD can come up with a fundamental explanation based on what I did.

First, this is NOT a SQL Server issue. It is an Active Directory replication issue.

Initially, I noticed event log entries on my SQL-hosting DC (which was not a GC server - yet) that the Net Logon service was paused due to replication problems. So I started it and it started, but after reboot it went back to paused.

I decided to use the Windows 2003 replmon.exe support tool to check into my DCs' replication status. Indeed, the DC hosting SQL Server showed broken replication from the PDC/GC DC.

Long story short, I made the DC hosting SQL a GC server also. Then, I opened AD Sites & Services on both DCs and deleted the automatically generated NTDS connections, then added my own manually. Left all settings at default (except of course which server was connected).

Then I used replmon.exe to "Synchronize each directory partition with all servers". Invoked this from both my DCs.

This seemed to do the trick. I could now add domain groups in SQL Server. Replmon.exe showed no more red x glyphs.

I had earlier tried replmon.exe and selecting "replicate now" for DC connections in Sites & Services leaving the automatically-generated connections in place. That was spotty, and while replmon.exe showed success a couple of times (no red x glyphs), shortly thereafter the red x glyphs reappeared and Users & Computers changes were no longer propagating.

That's when I created manual replication connections in Sites & Services. Crossing my fingers at this point... we'll see how it goes.

One final piece of info. My second DC - the one hosting SQL Server - is not a 24/7 machine. It is down (on purpose) quite a bit. Generally it is on every day for several hours, and it may or may not be on on weekends.

So, hopefully an AD wizard out there will see this and have a helpful epiphany.

BTW I can't resist one bit of carping. Why on Earth is a vital system tool like replmon.exe NOT in the default Windows 2003 install - meaning I have to go find the CD, then the support tools dir, then decide which of the msi and exe files to run, when unneeded end-user stuff like Windows Media Player, DirectX, and so on are on a default server install?

pelazem wrote:

I am having exactly the same problem.

Setup:

SQL Server 2000 Standard Edition SP4; service login account is a domain account that is a member of domain admins (it was not for normal operation; I added it to domain admins to see if login creation would work - it did not)

Windows 2003 Server Standard Edition, SP1 and all subsequent updates installed; it is an AD domain controller in a single-domain forest.

I am logging onto the DC with a domain admin username/password

DCs are replicating fine; I created a test group on one DC and saw it immediately on other DC. For this issue, tried creating a new group on first one DC, then the other (non-SQL Server) one.

As with the initial post, I can see all groups and users - incl. my newly created group - in the security pulldown, but selecting my group fails exactly as initial post specifies. I.e. I am not typing anything (so no typos), just picking from pre-populated lists.

Mixed authentication is enabled. Tried rebooting after creating AD group; still failed. Tried adding SQL Server to AD; still failed. Error message 15401 is unhelpful, nor does MS site have any further helpful info.

Infrastructure works fine; this is a small LAN, everything resolves etc.

The SQL Server has been operational for a month or so. *Nothing* else has been installed on this DC.

We do have some group policy settings in place; very minimal though. Does anyone know if anything in routine group policy could possibly prevent a domain admin logged into Windows 2003 from adding a login for a domain group when the SQL Server service is running under a (separate) domain admin account?

Any help is appreciated. Thanks.

UPDATE: I was able to add my domain group to the BUILTIN Administrators group using AD Users and Computers. The same domain group cannot be added in SQL Server as described above.

Mulhall wrote:

This is likely to be unrelated to SQL Server; check DNS is properly configured otherwise comms with DCs will be problematic - use ping, nslookup and arp commands to verify this.

Also, adding domain groups into local groups on the server, through compmgmt.msc > Local Users and Groups will deterimne if everythings okay at the OS level.

If that is working, it could be that the SQL Service is lacking in user rights, or the account you are interactively logged in with is either local or otherwise unable to enumerate accounts on the domain.

Authentication Issues

Current Setup:
Windows 2003 Server
SQL Server 2000 w/ SP3
Windows Sharepoint Servics

Problem:
I have created a group on our Domain (INT) called Domain Users. Inside this group I have added individual users that need to be there.

On the SQL Server when I try to add INT\Domain Users I get an error stateing that the user does not exist. Next I tried typing in INT and selecting the browse button. The window opens up listing all Domain users and groups including the one I added 'Domain Users'. I select Domain users from the Drop down list and hit OK. I then hit OK at the bottom of the Add User window and get the error User does not exist.

Any help or insight would be greatly appreciated.

Thank You
Tom McClung

Can you execute the following statement in Query Analyzer and post the output here:

sp_grantlogin 'INT\Domain Users'

Please post both the line containing the error number and error state, and the line containing the error message.

Thanks
Laurentiu

|||Server: Msg 15401, Level 11, State 1, Procedure sp_grantlogin, Line 41
Windows NT User or Group 'INT\Domain Users' not found. Check the name again.

Tom
|||Just a bit more information incase it's needed.

This server is not the domain controller. The domain controller is running Windows 2k Server software.

Tom
|||

Thanks for the information.

I have two additional questions:

(1) Are you able to add any INT user as a SQL login, or do you hit the same error for any INT principal that you attempt to add with sp_grantlogin.

(2) What was the tool that you were using to browse the domain users, which you mentioned in the initial email?

Not sure if it is related, but have you considered upgrading to SP4?

Thanks
Laurentiu

|||(1) The only one that was added was INT\Administrator. Every other INT account delivers the same error using sp_grantlogin.

(2) In the SQL server enterprise manager I went to the security folder and then clicked on logins. Then groups. In the group window at the top I typed in INT and clicked the browse button next to it. This brought up a drop down menu of all the INT users and groups correctly.

(3) I will download SP4 and test.

Tom
|||SP4 installed and I still have the same authentication issues.

I can see the INT domain users in the SQL Server Login menu but when I attempt to add the error comes up with user does not exist.

Tom
|||

What is the service account that SQL Server is running under? One possibility might be that the service account cannot query the INT domain. Did you add the Administrator account manually?

You could also attempt to install SQL Server Express and perform the same operation (as a precaution, you should backup your existing databases to avoid any loss). The error messages in SQL Server 2005 provide additional information that could help identify the issue. Make sure you set SQL Server Express to run under the same account as the existing SQL Server 2000 installation.

Thanks
Laurentiu

|||This is likely to be unrelated to SQL Server; check DNS is properly configured otherwise comms with DCs will be problematic - use ping, nslookup and arp commands to verify this.

Also, adding domain groups into local groups on the server, through compmgmt.msc > Local Users and Groups will deterimne if everythings okay at the OS level.

If that is working, it could be that the SQL Service is lacking in user rights, or the account you are interactively logged in with is either local or otherwise unable to enumerate accounts on the domain.|||Make sure u got checked mix authentication mode on ur server.|||

I am having exactly the same problem.

Setup:

SQL Server 2000 Standard Edition SP4; service login account is a domain account that is a member of domain admins (it was not for normal operation; I added it to domain admins to see if login creation would work - it did not)

Windows 2003 Server Standard Edition, SP1 and all subsequent updates installed; it is an AD domain controller in a single-domain forest.

I am logging onto the DC with a domain admin username/password

DCs are replicating fine; I created a test group on one DC and saw it immediately on other DC. For this issue, tried creating a new group on first one DC, then the other (non-SQL Server) one.

As with the initial post, I can see all groups and users - incl. my newly created group - in the security pulldown, but selecting my group fails exactly as initial post specifies. I.e. I am not typing anything (so no typos), just picking from pre-populated lists.

Mixed authentication is enabled. Tried rebooting after creating AD group; still failed. Tried adding SQL Server to AD; still failed. Error message 15401 is unhelpful, nor does MS site have any further helpful info.

Infrastructure works fine; this is a small LAN, everything resolves etc.

The SQL Server has been operational for a month or so. *Nothing* else has been installed on this DC.

We do have some group policy settings in place; very minimal though. Does anyone know if anything in routine group policy could possibly prevent a domain admin logged into Windows 2003 from adding a login for a domain group when the SQL Server service is running under a (separate) domain admin account?

Any help is appreciated. Thanks.

UPDATE: I was able to add my domain group to the BUILTIN Administrators group using AD Users and Computers. The same domain group cannot be added in SQL Server as described above.

Mulhall wrote:

This is likely to be unrelated to SQL Server; check DNS is properly configured otherwise comms with DCs will be problematic - use ping, nslookup and arp commands to verify this.
Also, adding domain groups into local groups on the server, through compmgmt.msc > Local Users and Groups will deterimne if everythings okay at the OS level.
If that is working, it could be that the SQL Service is lacking in user rights, or the account you are interactively logged in with is either local or otherwise unable to enumerate accounts on the domain.

|||

The authentication mode does not matter for the operation of creating a login.

Just to make sure I understand this setup: is SQL Server 2000 installed on the DC machine, or on a different machine?

Thanks
Laurentiu

|||

OK, I figured out how to at least fix the symptom temporarily. Maybe someone more expert than me at AD can come up with a fundamental explanation based on what I did.

First, this is NOT a SQL Server issue. It is an Active Directory replication issue.

Initially, I noticed event log entries on my SQL-hosting DC (which was not a GC server - yet) that the Net Logon service was paused due to replication problems. So I started it and it started, but after reboot it went back to paused.

I decided to use the Windows 2003 replmon.exe support tool to check into my DCs' replication status. Indeed, the DC hosting SQL Server showed broken replication from the PDC/GC DC.

Long story short, I made the DC hosting SQL a GC server also. Then, I opened AD Sites & Services on both DCs and deleted the automatically generated NTDS connections, then added my own manually. Left all settings at default (except of course which server was connected).

Then I used replmon.exe to "Synchronize each directory partition with all servers". Invoked this from both my DCs.

This seemed to do the trick. I could now add domain groups in SQL Server. Replmon.exe showed no more red x glyphs.

I had earlier tried replmon.exe and selecting "replicate now" for DC connections in Sites & Services leaving the automatically-generated connections in place. That was spotty, and while replmon.exe showed success a couple of times (no red x glyphs), shortly thereafter the red x glyphs reappeared and Users & Computers changes were no longer propagating.

That's when I created manual replication connections in Sites & Services. Crossing my fingers at this point... we'll see how it goes.

One final piece of info. My second DC - the one hosting SQL Server - is not a 24/7 machine. It is down (on purpose) quite a bit. Generally it is on every day for several hours, and it may or may not be on on weekends.

So, hopefully an AD wizard out there will see this and have a helpful epiphany.

BTW I can't resist one bit of carping. Why on Earth is a vital system tool like replmon.exe NOT in the default Windows 2003 install - meaning I have to go find the CD, then the support tools dir, then decide which of the msi and exe files to run, when unneeded end-user stuff like Windows Media Player, DirectX, and so on are on a default server install?

pelazem wrote:

I am having exactly the same problem.

Setup:

SQL Server 2000 Standard Edition SP4; service login account is a domain account that is a member of domain admins (it was not for normal operation; I added it to domain admins to see if login creation would work - it did not)

Windows 2003 Server Standard Edition, SP1 and all subsequent updates installed; it is an AD domain controller in a single-domain forest.

I am logging onto the DC with a domain admin username/password

DCs are replicating fine; I created a test group on one DC and saw it immediately on other DC. For this issue, tried creating a new group on first one DC, then the other (non-SQL Server) one.

As with the initial post, I can see all groups and users - incl. my newly created group - in the security pulldown, but selecting my group fails exactly as initial post specifies. I.e. I am not typing anything (so no typos), just picking from pre-populated lists.

Mixed authentication is enabled. Tried rebooting after creating AD group; still failed. Tried adding SQL Server to AD; still failed. Error message 15401 is unhelpful, nor does MS site have any further helpful info.

Infrastructure works fine; this is a small LAN, everything resolves etc.

The SQL Server has been operational for a month or so. *Nothing* else has been installed on this DC.

We do have some group policy settings in place; very minimal though. Does anyone know if anything in routine group policy could possibly prevent a domain admin logged into Windows 2003 from adding a login for a domain group when the SQL Server service is running under a (separate) domain admin account?

Any help is appreciated. Thanks.

UPDATE: I was able to add my domain group to the BUILTIN Administrators group using AD Users and Computers. The same domain group cannot be added in SQL Server as described above.

Mulhall wrote:

This is likely to be unrelated to SQL Server; check DNS is properly configured otherwise comms with DCs will be problematic - use ping, nslookup and arp commands to verify this.

Also, adding domain groups into local groups on the server, through compmgmt.msc > Local Users and Groups will deterimne if everythings okay at the OS level.

If that is working, it could be that the SQL Service is lacking in user rights, or the account you are interactively logged in with is either local or otherwise unable to enumerate accounts on the domain.

sql

Auotincrement without using autoincrement

Hi Lee,
have you thought about using a counter table. Normally something like
Create table Counter (TableName sysname, IDValue int)
What you do is for each table in your database that requires a increasing
number set the tablename and IDValue to 0 then in a transaction you update
the value then retrieve it do your inserts and then commit
i.e
begin transaction
declare @.ID as int
update Counter IDValue=IDVale +1 where TableName='mastertable'
select @.ID=IDValue from Counter where TableName='mastertable'
-- no do your inseertts
insert into other tbales using the @.ID
..
...
commit transaction
Because the counter table is locked during the update no one can get the
next value. If the transaction aborts the the update is rolled back. Also
it's quick as you don't have to go through the larger table to get the max
(even with an index). Obviously you would have a clustered index on the
TableName column or a covering index on both columns,...
Lee don't be too bothered about Joe's (CELKO) comments . He has been a bit
bashed lately (in the forum) and turned a bit rabid. His comments are way
off the mark. It would of been nice to see such expert in the field of SQL
give help instead of put down someone asking for help.
kind regards
Greg O
Need to document your databases. Use the firs and still the best AGS SQL
Scribe
http://www.ag-software.com
"Lee Gillie" <Lee@.nospam.odp.com> wrote in message
news:uxoaocRnFHA.2904@.TK2MSFTNGP14.phx.gbl...
>I have a master table which I have been updating in multiple queries to
>create a new row. It has a primary key, call it WorkID. I can't make it
>autoincrement. And it is more complicated because...
> WorkID can also appear in two other tables, as references to the master
> record, but I need to provide for the master record being gone, and as
> such the records in the other two tables are orphaned. That is fine.
> To create a new master record I select MAX(WorkID) unioned on all 3
> tables, and increment the result, and this is my new WorkID. However, even
> if in a transaction, this query work can result in duplicate WorkID
> numbers when new masters are created in extremely rapid succession. I see
> the flaw here. Don't think this approach can be salvaged when the MAX and
> INSERT queries are done separately.
> I have been racking my brain to find a way to deal with this WITHOUT
> resorting to auto-increment on the master table. I can think of no
> expression for an INSERT value which will take the MAX+1 of WorkID on the
> three tables, but it seems there must be a way to do this in a single
> statement. Something like:
> INSERT WORK (WorkID) VALUES (SELECT MAX(WorkID)+1 FROM ... UNION ... )
> Maybe I need a new single row, single column table that arbitrates new
> WorkID values? Or maybe someone has a favorite trick?
> Thx - LeeGreg -
I like it!
I appreciate ALL the replies. I learned some stuff, so I got better at
my job, and my project is nearer the BRICK HOUSE I am striving for.
Thanks everyone for taking a moment to consider this and sharing your
thoughts.
Also... I never let anyone else's bad day bring me down. Life is way too
short. But even so, if you are open to it, you can learn something from
anyone.
Best regards - Lee
Pay it forward!|||The problem here (other than slightly incorrect syntax :) is that you are
single threading all inserts in your system. They all have to wait on the
transaction to complete to get the next value. Serious hog on concurrency.
An idea I have used just have a table for getting surrogate values if you
can afford to do this one row at a time and keep the table pared down:
create table counter
(
counterId int identity(1,1) primary key
)
go
insert into counter
default values
select scope_identity()
---
1
Here at least there will be no single threading. A delete job could keep
this table really small well over 1500 should fit on a single page so just
delete all but the last few hundred. Make sure you get a good plan on that
query because if you table scan you will make everyone wait on the clean up.
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"GregO" <grego@.community.nospam> wrote in message
news:uUxOwCXnFHA.1148@.TK2MSFTNGP12.phx.gbl...
> Hi Lee,
> have you thought about using a counter table. Normally something like
> Create table Counter (TableName sysname, IDValue int)
> What you do is for each table in your database that requires a increasing
> number set the tablename and IDValue to 0 then in a transaction you update
> the value then retrieve it do your inserts and then commit
> i.e
> begin transaction
> declare @.ID as int
> update Counter IDValue=IDVale +1 where TableName='mastertable'
> select @.ID=IDValue from Counter where TableName='mastertable'
> -- no do your inseertts
> insert into other tbales using the @.ID
> ..
> ...
> commit transaction
> Because the counter table is locked during the update no one can get the
> next value. If the transaction aborts the the update is rolled back.
> Also it's quick as you don't have to go through the larger table to get
> the max (even with an index). Obviously you would have a clustered index
> on the TableName column or a covering index on both columns,...
> Lee don't be too bothered about Joe's (CELKO) comments . He has been a
> bit bashed lately (in the forum) and turned a bit rabid. His comments are
> way off the mark. It would of been nice to see such expert in the field
> of SQL give help instead of put down someone asking for help.
> --
> kind regards
> Greg O
> Need to document your databases. Use the firs and still the best AGS SQL
> Scribe
> http://www.ag-software.com
>
> "Lee Gillie" <Lee@.nospam.odp.com> wrote in message
> news:uxoaocRnFHA.2904@.TK2MSFTNGP14.phx.gbl...
>|||Hi Louis,
I agree about the delay in my solution but sometimes you need to be sure and
wait for a transaction. In the solution I put forward you have the other
bonus of never missing a number. Unlike identity and doing without a
transaction (not that the user said this was an issue)
Either way if the transactions are small then the delay shouldn't be an
issue
kind regards
Greg O
"Louis Davidson" <dr_dontspamme_sql@.hotmail.com> wrote in message
news:eZ04akinFHA.3316@.TK2MSFTNGP14.phx.gbl...
> The problem here (other than slightly incorrect syntax :) is that you are
> single threading all inserts in your system. They all have to wait on the
> transaction to complete to get the next value. Serious hog on
> concurrency.
> An idea I have used just have a table for getting surrogate values if you
> can afford to do this one row at a time and keep the table pared down:
> create table counter
> (
> counterId int identity(1,1) primary key
> )
> go
> insert into counter
> default values
> select scope_identity()
> ---
> 1
> Here at least there will be no single threading. A delete job could keep
> this table really small well over 1500 should fit on a single page so just
> delete all but the last few hundred. Make sure you get a good plan on
> that query because if you table scan you will make everyone wait on the
> clean up.
> --
> ----
--
> Louis Davidson - http://spaces.msn.com/members/drsql/
> SQL Server MVP
>
> "GregO" <grego@.community.nospam> wrote in message
> news:uUxOwCXnFHA.1148@.TK2MSFTNGP12.phx.gbl...
>|||That is true, just wanted to make sure that you realized that no more than
one user at a time could insert data into any table using your system. If
you can live with that, it is .
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"GregO" <grego@.community.nospam> wrote in message
news:OFavurinFHA.2444@.tk2msftngp13.phx.gbl...
> Hi Louis,
> I agree about the delay in my solution but sometimes you need to be sure
> and wait for a transaction. In the solution I put forward you have the
> other bonus of never missing a number. Unlike identity and doing without
> a transaction (not that the user said this was an issue)
> Either way if the transactions are small then the delay shouldn't be an
> issue
> kind regards
> Greg O
>
> "Louis Davidson" <dr_dontspamme_sql@.hotmail.com> wrote in message
> news:eZ04akinFHA.3316@.TK2MSFTNGP14.phx.gbl...
>